Fix Foundry blockhash ordering and CI cache cleanup

[MontrealAI]

Motivation

• Foundry fuzz tests were failing with vm.setBlockhash: block number must be less than or equal to the current block number because tests set blockhashes for future blocks.
• CI was noisy due to unsupported forge_version keys in foundry.toml producing warnings.
• Foundry deserialization errors (foundry_compilers::cache) suggested stale/corrupted incremental compiler cache was being restored by CI.

Description

• Added a helper function _rollPastAndSetBlockhash(uint256, bytes32) and replaced direct vm.setBlockhash(...) calls in test/v2/ValidatorStakeLock.t.sol, test/v2/ValidationFinalizeGas.t.sol, and test/v2/ValidatorSelectionFuzz.t.sol so the target block is always in the past before calling vm.setBlockhash.
• Removed unsupported forge_version profile keys from foundry.toml to silence Foundry warnings.
• Cleared the potentially stale Foundry compiler cache (rm -f cache/solidity-files-cache.json || true) prior to running forge test in the Foundry CI jobs (.github/workflows/fuzz.yml, .github/workflows/ci.yml, and .github/workflows/contracts.yml).

Testing

• No Foundry tests were executed locally because forge is not available in the environment (error: forge: command not found).
• Recommended local verification commands: forge test --match-path test/v2/ValidatorStakeLock.t.sol -vvvv and forge test -vvvv --ffi --fuzz-runs 256 --match-contract 'CommitReveal|Stake|Fee|Slashing'.
• CI will now clear the stale cache before running forge test, and Foundry jobs are expected to stop surfacing the previous deserialization error and the vm.setBlockhash failures once the workflows run.

---

Codex Task