fix(miner): write fork hash into block header extra_data vanity bytes

[deszhou]

Description

finalize_new_header left extra_data vanity bytes [28..32] as zeros (a TODO from the original port). These bytes carry the current fork hash, which snapshot.apply() reads to populate snapshot.recent_fork_hashes. This fix writes fork_id(number, timestamp).hash into those bytes, aligning with the Parlia Prepare method in go-bsc.

Rationale

Without this fix, parlia_getSnapshot always returns "00000000" for
recentForkHashes on reth-bsc produced blocks, making it impossible to verify
which fork a validator was on when producing a block.

Example

parlia_getSnapshot on a locally mined block (block 5, local chain):

Before

"recent_fork_hashes": {"5": "00000000"}

After

"recent_fork_hashes": {"5": "e4d5334c"}

Changes

Notable changes:

• src/node/miner/util.rs — replace TODO block with fork hash write into extra_data vanity bytes; add unit test
• src/node/evm/assembler.rs — propagate + Hardforks bound to BlockAssembler impl (EthereumHardforks does not extend Hardforks)

Potential Impacts

• No consensus impact — recent_fork_hashes is only consumed by parlia_getSnapshot RPC and snapshot window cleanup, not by block validation

[hashdit-bot]

Pull Request Review

This PR updates the BSC miner/header finalization flow to write the current fork hash into the last 4 bytes of the extra_data vanity segment ([28..32]), replacing the previous TODO/zero behavior. It also adds the Hardforks trait bound where needed so fork_id() can be computed from the chain spec in both miner and assembler contexts. A new unit test verifies the fork-hash write behavior, alongside existing timestamp/finalization tests.

Sensitive Content

No sensitive content detected.

Security Issues

No serious security issues detected.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[deszhou]

cc @chee-chyuan