feat(fast-inbox): let the proposer choose between immediate and L1-confirmed inbox consumption

[spalladino]

Exposes to operators the choice the proposer makes about when an L1-to-L2 message becomes consumable, and makes the impatient setting safe to run.

The flag

SEQ_INBOX_L1_CONFIRMATIONS (config inboxL1Confirmations), values 0 or 1, default 0. Anything else is rejected at startup with a message naming the two supported values, and rejected the same way on a runtime config update (pickFromSchema trusts its input, so the in-process update path had no validation of its own).

• 0 — immediate. Consume an Inbox bucket as soon as the local archiver has it, so a bridged message reaches L2 in the next block the proposer builds.
• 1 — one L1 confirmation. Consume only once another L1 block has built on the bucket's opening block: the descendant-confirmed rule from feat(fast-inbox): consume inbox buckets once their L1 block has a canonical descendant #25351, which costs roughly one Ethereum slot (~12s) of extra latency per message.

The default is 0 because the lag simulator bounds the price of impatience at about 0.07% of slots — one or two a day network-wide — assuming ten one-block L1 reorgs per day and messages present in 30% of L1 blocks. That is an upper bound: a reorg that re-mines the same messages costs nothing, because the proposer re-resolves what it consumed before publishing, so only a reorg that reorders or drops those messages actually loses the slot. Nothing worse than a lost slot happens: the chain is unaffected, and the next proposer consumes the message. Waiting buys back those slots and pays ~12s of latency on every message.

The automine sequencer ignores the setting and always consumes immediately, since its L1 mines on demand. The node's next-block public-call simulator now reads the same setting, so a transaction is only admitted against a bundle the proposer will actually consume — it previously hardcoded the confirmed rule — and it is told about runtime updates to the setting rather than holding the config object it was constructed with.

Bucket re-resolution by content

Immediate consumption exposes the proposer to exactly one hazard: an L1 reorg that re-times a bucket it has already consumed. Under the message-only rolling hash a re-time leaves the hash untouched, so the sealed checkpoint header stays valid on L1 — but a reorg that merges buckets shifts every sequence number after the merge point, and a sequence number captured when the bundle was selected would point L1, and peers, at a bucket whose rolling hash no longer matches the header.

So the bucket is resolved by content rather than carried forward, via a new getInboxBucketByRollingHash:

• Before each block proposal is signed, the consumption cursor is re-pointed at the bucket that currently carries its rolling hash. This has to happen before signing: the reference is covered by the proposal signature, and slashing protection refuses a second signature for the same duty, so a reference that goes stale after signing cannot be corrected. Without this the L1 hint and the gossiped proposal disagreed after a merge, and validators rejected the proposal on a rolling-hash mismatch for a checkpoint L1 would have accepted.
• Before the checkpoint proposal is gossiped, and once more before enqueueProposeCheckpoint (attestation collection takes seconds; the second check is one store read), the L1 propose hint is resolved from the rolling hash the sealed header commits to — the value L1 compares the hint's bucket against — rather than from the cursor that tracked it.

A changed sequence number is logged at info. When no bucket carries the hash at all the consumed prefix no longer ends on a bucket boundary — a reorder or a dropped message — and the slot is abandoned with an inbox_bucket_reorged failure rather than sending a propose that would revert.

The mandatory-consumption floor is re-checked at the resolved bucket as part of that last step, so a bucket that syncs after the checkpoint was built (or one the reorg moved under the cutoff) abandons the slot locally instead of being caught by L1 reverting the propose.

Archiver index and database version

This needs a new L1ToL2MessageSource.getInboxBucketByRollingHash, backed in the archiver by a rollingHash → seq index alongside the bucket snapshots. The index is written wherever a snapshot is written and cleaned wherever one is deleted or rewritten (the existing rewind helper), so every removal path is covered by construction; a stale entry can only cost a read, since the bucket it names is confirmed to carry the hash before it is returned. Fr.ZERO resolves the genesis sentinel.

ARCHIVER_DB_VERSION goes to 10 for it: the index is only written as buckets are stored, so a database carried over from an earlier build would hold buckets the index does not name and answer those lookups with "no such bucket". Nodes rebuild the archiver store on first start and resync from L1.

Validators are unchanged

No validator code changed, deliberately. Check 1 looks the bucket up by seq and compares only the rolling hash — never the timestamp — so a re-timed bucket is accepted as-is, and #25342's single forced re-sync on bucket_hash_mismatch covers a validator sitting on the orphaned side of the reorg. With the proposer now re-resolving before it signs, a merge that shifts seq no longer costs it the attestations of validators that already see the merge; a proposal signed before the merge lands still can, which no proposer-side change can fix. Checking by content on the validator side is a possible later iteration, not part of this PR.

New configuration

SEQ_INBOX_L1_CONFIRMATIONS is new and defaults to the behaviour described above; nothing existing changes value. Nodes running either setting interoperate, so a fleet can be rolled in any order. Documented in the developer inbox page and in a new operator changelog page, which also carries the resync note. The bridge tutorials no longer describe the one-confirmation wait as live-network behaviour.

Tests

• sequencer-client/src/config.test.ts: default 0, 1 accepted, 2 and abc rejected with the two supported values named.
• sequencer.test.ts: a runtime update to an unsupported depth is rejected and leaves the running config untouched.
• checkpoint_proposal_job.test.ts: no L1 reads at depth 0; the opening block's child read at depth 1; a merge re-seating the rolling hash publishes the new sequence number and signs the block proposal against it; the same reorg landing during attestation collection is caught by the pre-submission lookup, which can only correct the L1 hint; a bucket becoming mandatory during attestation collection leaves nothing enqueued; a vanished rolling hash abandons the slot before broadcast, and after broadcast leaves nothing enqueued.
• node_public_calls_simulator.test.ts: prediction follows a runtime depth change, and keeps the configured depth when an update leaves it out.
• message_store.test.ts: resolve by rolling hash, the genesis zero hash, index cleanup for buckets a removal deletes or rewrites, and a hash resolving to the bucket a merge moved it to.
• archiver-sync.test.ts: the existing fake_l1_state re-time / merge / reorder reorg cases now also assert what a proposer holding the pre-reorg rolling hash resolves afterwards — the same sequence number, the merged one, and nothing. A single test spanning build → re-time → publish is not expressible at unit level (the proposer suite mocks its message source and the archiver suite has no proposer), so the two halves are covered separately.
• proposal_handler.test.ts: a proposal referencing a re-timed bucket (same seq, same hash, new timestamp) is attested with no forced sync.

Gates: full yarn build, yarn format, yarn lint; sequencer-client 279 passed / 1 skipped, archiver 601/601, aztec-node 183/183, validator-client 274 passed / 3 skipped. No e2e.

Stacked on #25354

Fixes A-1881