feat(chainspec): binary-authoritative hardfork schedule for gravity chains

[nekomoto911]

Summary

Make the gravity-sdk binary the authoritative source of hardfork
activation for the chain ids it owns (today: gravity mainnet
127001). Introduces GravityChainSpecParser in
bin/gravity_node/src/chainspec.rs that wraps upstream
EthereumChainSpecParser and applies a compile-time override table to
the alloy_genesis::Genesis value on the file / inline-JSON fallthrough
path, before From<Genesis> for ChainSpec runs in greth.

Initial table on GRAVITY_MAINNET_CHAIN_ID = 127001:

• prague_time: Some(1_782_709_200) — governance-pinned to the value in gravity-mainet-gitops/genesis.json.
• alpha_time: None — forward-defence: no timestamp has been chosen onchain yet; operator-supplied alphaTime in mainnet genesis is dropped before EL or CL reads it.

For any chain id not in the table, the parser is a no-op and current genesis-driven behaviour is unchanged. Named chains (mainnet/sepolia/holesky/hoodi/dev) delegate to upstream unchanged — none of those are gravity-owned.

Why mutate Genesis before construction?

Two big properties fall out of running the override at parse time:

1. The constructed Arc<ChainSpec> is correct from t=0. genesis_header, fork_id, fork_filter and the inner SealedHeader::hash OnceLock all derive from the post-override hardforks, with no post-construction mutation, no Arc::get_mut/Arc::make_mut, no recompute path.
2. EL and CL see one consistent view. The CL side (gaptos ConsensusHardforks::from_genesis_extra_fields, bin/gravity_node/src/main.rs:107-118) reads from chain_spec.genesis.config.extra_fields. Because we mutate extra_fields at parse time, a single alpha_time entry in the table forward-defends both layers — no parallel CL table, no CL-side code change. When governance picks a timestamp for Alpha, flipping alpha_time: None to Some(ts) pins both layers to the same authoritative value.

How does it plug in?

The Cli<C> framework was already generic over C: ChainSpecParser with EthereumChainSpecParser only as the default. Swap the default + three type annotations:

-pub(crate) struct Cli<C: ChainSpecParser = EthereumChainSpecParser, ...>
+pub(crate) struct Cli<C: ChainSpecParser = GravityChainSpecParser, ...>

Also fixes a stray hardcoded FnLauncher::new::<EthereumChainSpecParser, _> inside the generic impl that should have been FnLauncher::new::<C, _>.

Test plan

• RUSTFLAGS='--cfg tokio_unstable' cargo test -p gravity_node --bin gravity_node chainspec:: → 12/12 pass
  • Named-chain delegation (mainnet/sepolia/holesky/hoodi/dev all parse)
  • Prague override (genesis supplies a different value / omits it / testnet passthrough)
  • Shanghai/Cancun untouched
  • Alpha forward-defence (genesis supplies alphaTime / omits it / testnet passthrough)
  • Post-override chain_spec.genesis reflects the table (unified-view invariant)
  • From<Genesis> is idempotent on the same parsed JSON
  • ChainSpecBuilder::mainnet() bypass tripwire (currently safe: chain id 1, not 127001)
  • Governance pin tripwire: Prague timestamp == 1_782_709_200
• cargo fmt -p gravity_node --check
• CI

Relationship to gravity-reth PR #369

This is the "Option D-1" alternative to Galxe/gravity-reth#369, which placed the same override inside greth's impl From<Genesis> for ChainSpec. D-1 trades:

Gain:

• One repo, one table, naturally unifies EL+CL — no greth fork burden, no parallel CL table.
• Fixes a latent admin_nodeInfo RPC inconsistency in feat: use pending txn as iterator #369 (where operator-supplied pragueTime wins over the override in the spread at crates/rpc/rpc/src/admin.rs:114-141).

Lose:

• From<Genesis> is no longer the chokepoint. Any greth-internal code path that constructs a ChainSpec from a Genesis on chainId 127001 without going through the sdk parser silently skips the override. Today no such production path exists; the tripwire test covers the most likely accidental case.

The two PRs are mutually exclusive — only one should land. Discussion welcome.

Maintenance

Adding or modifying an entry in the table for a shipped chain id is a consensus change. The PR doing so must reference the onchain governance / coordination record that authorised the timestamp. Existing entries must never be removed; promoting None to Some(ts) is the only allowed transition.

[nekomoto911]

Tracked from review:

• chainspec override: document hardfork promotion preconditions (Alpha) #764 — document Alpha promotion preconditions (the "forward-defends both layers" claim only holds once a Fix block buffer readiness and execution epoch handling #755-style wrapper routes the CL through alphaTime; promoting alpha_time: None → Some(ts) before that lands would silently break CL activation).
• chainspec override: also strip legacy 'consensusAlpha' key when alpha_time = None #765 — also strip legacy consensusAlpha key in apply_overrides when alpha_time = None, to close the remaining forward-defence gap.

Neither is a blocker for this PR as it stands today (mainnet extraFields: {} makes both no-ops), but both should be resolved before promoting alpha_time off None.