feat(evm): derive EthereumHardfork from ChainConfig (#199)

* feat(evm): derive EthereumHardfork from ChainConfig

Add methods to determine active hardforks from an alloy ChainConfig at
a given block number and timestamp. This bridges the gap between alloy's
genesis chain configuration and the SDK's EthereumHardfork bitflags.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* feat(evm): add bit_for_spec_id compilation canary

Add exhaustive SpecId -> EthereumHardfork match that will fail to
compile when revm adds a new SpecId variant, ensuring our hardfork
mappings stay in sync.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* feat(evm): add ChainConfig compilation canary

Exhaustive destructure of ChainConfig that will fail to compile when
alloy adds a new field, ensuring active_hardforks stays in sync.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(evm): address PR review comments

Exclude BPO forks from latest_hardfork since they only change blob
parameters, not EVM semantics. Add doc note that Amsterdam is not yet
in ChainConfig. Add test for BPO exclusion.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* feat(evm): add cumulative from_spec_id conversion and fix doc link

Add `from_spec_id` to convert a SpecId into the cumulative set of
EthereumHardfork flags (that spec plus all predecessors, excluding BPO
forks). Fix broken rustdoc link to private `chain_config_canary`.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* simplify from_spec_id: don't exclude BPO forks

BPO forks are no-ops for EVM semantics and are always activated before
Amsterdam on mainnet, so including them in the cumulative set is
harmless and simplifies the implementation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Author: prestwich