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

[emlautarom1-agent]

Part of #402 — follow-up to the app-wiring PR.

Scope

Derive the network from the cluster lock's fork version and force-enable GnosisBlockHotfix for gnosis/chiado unless the user explicitly disabled it (Charon app/app.go:181-196 at v1.7.1: ForkVersionToNetwork + EnableGnosisBlockHotfixIfNotDisabled). The Feature::GnosisBlockHotfix doc comment already promises this behavior; run never does it, so gnosis/chiado clusters would sign proposals over the wrong block hash.

Structural prerequisite: AppConfig currently carries a resolved Arc<FeatureSet>, but enable_gnosis_block_hotfix_if_not_disabled needs &mut FeatureSet and the featureset::Config, and the network is only known after lock load. Change AppConfig to carry pluto_featureset::Config and resolve the FeatureSet inside run() after lock load (then wrap in Arc); update the CLI bridge (build_feature_set in crates/cli/src/commands/run.rs) accordingly. The pieces already exist: fork_version_to_network (crates/eth2util/src/network.rs) and enable_gnosis_block_hotfix_if_not_disabled (crates/featureset/src/lib.rs).

Dependencies

None, but coordinate with anyone touching AppConfig/the CLI bridge.

Acceptance

• gnosis/chiado lock fork version → feature enabled unless explicitly disabled via --feature-set-disable.
• Other networks unaffected; explicit disable respected (matches the existing featureset unit test semantics).
• CLI bridge passes the featureset Config through; resolution happens post-lock-load.