feat(app): auto-enable GnosisBlockHotfix for gnosis/chiado from the lock fork version

[emlautarom1-agent]

Closes #530

Summary

Gnosis/Chiado clusters must sign block proposals over a chain-specific SSZ block hash; the GnosisBlockHotfix feature switches Pluto to that behavior. Charon force-enables it automatically whenever the cluster's network is gnosis or chiado — unless the operator explicitly disabled it — deriving the network from the cluster lock's genesis fork version. Pluto's feature doc already promised this, but pluto run never performed it, so a gnosis/chiado cluster would sign over the wrong block hash.

This is a follow-up to #536 (which introduced the run command and the core-node app wiring). It edits those structures rather than adding parallel ones: AppConfig now carries a pluto_featureset::Config instead of a pre-resolved Arc<FeatureSet>, and the FeatureSet is resolved inside App::run once the lock is loaded and the network is known. The CLI bridge just parses the feature flags into that config and forwards it.

The pieces this builds on already existed: fork_version_to_network and FeatureSet::enable_gnosis_block_hotfix_if_not_disabled. What was missing was the wiring that connects the lock's fork version to the feature-set resolution.

Differences from Charon

Charon validates the minimum feature-set status up front and applies the gnosis/chiado auto-enable later; Pluto does both together when it resolves the feature set after lock load (the auto-enable needs the network, which is only known once the lock's fork version is available). The only observable effect is timing: a value that parses as a status but is not a valid minimum status (enable, disable, sentinel) is rejected after the lock loads rather than before it. Genuinely unknown status strings (e.g. foo) still fail fast at CLI parse time, and either way the node never starts.

[emlautarom1]

Manually checked, mostly config plumbing. LGTM.

[Copilot]

Pull request overview

This PR fixes a correctness gap in pluto run by resolving the FeatureSet only after the cluster lock is loaded, then auto-enabling GnosisBlockHotfix for gnosis/chiado based on the lock’s genesis fork version (unless explicitly disabled). This aligns runtime behavior with the existing feature documentation and Charon’s behavior, preventing gnosis/chiado nodes from signing proposals over the wrong block hash.

Changes:

• Change the run CLI → app bridge to forward a pluto_featureset::Config instead of a pre-resolved Arc<FeatureSet>.
• Resolve the FeatureSet inside App::run once the lock (and fork version) is available, and apply gnosis/chiado auto-enable logic there.
• Add app-level unit tests covering gnosis/chiado auto-enable, explicit disable, other networks, and unknown fork versions.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
crates/cli/src/commands/run.rs	Forward featureset::Config through AppConfig and adjust tests to assert behavior via resolved FeatureSet.
crates/app/tests/simnet.rs	Update simnet test wiring to use pluto_featureset::Config::default() in AppConfig.
crates/app/src/node/mod.rs	Resolve FeatureSet post-lock-load and auto-enable GnosisBlockHotfix for gnosis/chiado; add unit tests for the resolver.
crates/app/src/node/config.rs	Replace feature_set: Arc<FeatureSet> with feature: pluto_featureset::Config in AppConfig.
crates/app/Cargo.toml	Move pluto-eth2util to normal deps so app code can derive network from fork version.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.