This commit implements a fork detection mechanism in the whitelist milestone validation system to resolve synchronization issues that occur when nodes sync from new milestone with extremely low latency. The problem was that nodes on different chain forks would be unable to sync with peers due to milestone validation rejecting chains with different block hashes, leading to "mismatch error" failures.

Root Cause Analysis:
The issue was caused by chain fork lock-in where milestone validation prevented nodes stuck on wrong forks from syncing to the correct canonical chain. Debug logs revealed that different nodes had different block hashes for the same block numbers, confirming a fork scenario where milestone validation was blocking recovery.

Solution Implemented:
- Added ChainReader interface to milestone validation for blockchain access
- Implemented fork detection logic in IsValidPeer method that checks if local blockchain has different hash than milestone hash for the same block number
- When a fork is detected, the validation allows peer synchronization to proceed, enabling automatic recovery to the canonical chain
- Added SetBlockchain method to inject blockchain reference after both whitelist service and blockchain are initialized (avoiding circular dependency)
- Updated service creation in eth/backend.go to set blockchain reference after initialization

When checkpoint verifier inserts canonical chain after rewind, the fork choice
logic in writeBlockAndSetHead() may determine that no reorg is needed, causing
blocks to be inserted with SideStatTy instead of CanonStatTy. This prevents
writeHeadBlock() from being called, leaving canonical hash mappings outdated.

The issue manifests as:
- "Successfully inserted canonical chain" log appears
- GetBlockByNumber() still returns old block hash
- Fork detection triggers false positives for whitelisted blocks
- Milestone reorg protection fails

Fix by explicitly calling SetCanonical() after InsertChain() to force
canonical status and ensure proper canonical hash mapping updates.

eth: fix canonical chain state inconsistency in checkpoint verifier

…rite the state sync records for a range of blocks (#1597)

…age after heimdall (v1 -> v2) migration (#1598)

* consensus/bor, params: added OverrideStateSyncRecordsInRange to overwrite the state sync records for a range of blocks

* amoy: added blocks in the OverrideStateSyncRecordsInRange for the outage after heimdall (v1 -> v2) migration

Merge v2.2.4 beta candidate to master

This is to fix a problem when the node is stuck at a loop when it is initially started and trying to whitelist the first milestone.
Instead of tracking all the block from the genesis, the metrics should just update the from the start block in the milestone.

Fix milestone whitelist delay on restart

Use larger runner for goreleaser