feat: gate unstake behind a fork and discover activations in the worker

[prajwolrg]

Description

Stacked on #187, which defined the fork schedule/params types but left them unconsumed. This PR is the first consumer: it puts the worker through a real fork boundary, using unstake as the example feature. The fork keeps its ForkId::Fork1 placeholder name — the bridge gates unstake txs on it, the admin AsmStfVkUpdate action carries the raw id of the fork the new proving artifact implements (rendered into the signing message, so the multisig authorizes the fork id alongside the predicate hash), the emitted AsmStfUpdate log forwards it, and the worker activates the named fork from the next block on, persisting the activation. The chain is the single authority on which fork an upgrade activates: there is no per-operator config to distribute, so a worker cannot silently diverge from the network by missing or misconfiguring one.

The fork id travels as a raw u16 rather than the ForkId enum because the upgrade that activates a fork is enacted by the artifact that predates it — the wire format cannot require knowing the fork. The worker maps ids it knows; an update naming an already-active fork is a logic-neutral VK rotation, and one naming an unknown id is skipped loudly (a binary that cannot apply the fork's rules cannot meaningfully activate it either).

The subtle part is crash/reorg safety, which is carried entirely by ordering: the activation record is written before the enacting block's anchor commit (a committed anchor can never lack its activation), and every sync rebase prunes activations above the base before re-processing (a reorged-out enactment cannot leak into the new branch — its blocks re-discover whatever survives). The activation height is derived, not stored: it is always the block after the enacting one, so ForkActivation records only (enacting_height, fork).

Deliberately out of scope: the prover side (switching proving artifacts across VK upgrades) stays in #183. At the worker level nothing verifies proofs; the new predicate is carried opaquely.

Default behavior is unchanged: unstake remains active since genesis in production params, so a VK update naming Fork1 there acts as a rotation.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency update
• Security fix

Notes to Reviewers

Suggested entry point: the fork id on the action in crates/subprotocols/admin/txs/src/actions/updates/asm_stf_vk.rs (and what it renders for signers), then the activation discovery and rollback in crates/worker/src/state.rs, then the bridge gate in crates/subprotocols/bridge-v1/subprotocol/src/handler.rs — note the gate decides identically in both tx-processing phases, so pre-fork the aux request is never made and aux request/consumption stay in lockstep.

Breaking surface: AsmStfVkUpdate and the AsmStfUpdate log gain a mandatory raw fork id, changing their SSZ layout and the rendered signing message (nothing deployed consumes the old layout).

Tested at two levels, no prover involved: unit tests for the gate boundary and the worker's discovery (activation of the named fork, already-active forks treated as logic-neutral rotations, unknown fork ids skipped, restart resume, rebase rollback), and a worker-level regtest integration test driving the full choreography — genuine musig2-signed unstake ignored pre-fork, admin VK upgrade enactment activates the fork at H+1, the same unstake then removes the operator — plus the reorg path where abandoning the submission block rolls the activation back until the new branch re-enacts it.

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

Part of #183 (fork-based ASM upgradeability), stacked on #187.

[codecov]

Codecov Report

❌ Patch coverage is 94.84979% with 24 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/storage/src/sled/fork_activation.rs	88.88%	10 Missing ⚠️
bin/asm-runner/src/worker_context.rs	70.58%	5 Missing ⚠️
...tocols/admin/txs/src/actions/updates/asm_stf_vk.rs	63.63%	4 Missing ⚠️
crates/worker/src/test_utils.rs	86.36%	3 Missing ⚠️
.../subprotocols/bridge-v1/subprotocol/src/handler.rs	98.14%	2 Missing ⚠️

Files with missing lines	Coverage Δ
bin/asm-runner/src/bootstrap.rs	99.14% <100.00%> (ø)
bin/asm-runner/src/storage.rs	100.00% <100.00%> (ø)
crates/common/src/fork.rs	98.93% <100.00%> (ø)
...tes/extensions/prover/worker/src/backend/native.rs	72.72% <100.00%> (ø)
crates/logs/src/asm_stf.rs	100.00% <100.00%> (ø)
crates/proof/statements/src/program.rs	85.41% <100.00%> (ø)
crates/storage/src/sled/mod.rs	100.00% <ø> (ø)
...ates/subprotocols/admin/subprotocol/src/handler.rs	92.57% <100.00%> (ø)
...protocols/bridge-v1/subprotocol/src/subprotocol.rs	91.60% <100.00%> (ø)
crates/worker/src/builder.rs	91.30% <ø> (ø)
... and 8 more

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Commit: 57e4fb2
SP1 Execution Results

program	cycles	gas
asm-stf	136,419,144	134,136,555
moho	5,223,535	5,525,318

[prajwolrg]

Superseded by #204, which reworks this on top of the spec-versioning model from #202 (base: asm-upgradability). The fork terminology is gone — the admin action now carries the raw spec version (u16) its artifact implements, V0 is the genesis spec — and the unstake gate is dropped since nothing consumes the schedule yet.