feat(fast-inbox): single variable-size InboxParity proof per checkpoint (A-1427)

[spalladino]

Replaces the parity base (×4) + parity root fan-in with one variable-size InboxParity<S> proof per checkpoint, S ∈ {64, 256, 1024} (one VK per size; the prover proves the smallest rung ≥ the checkpoint's message count). The parity-root circuit is deleted; the checkpoint root keeps a single parity verification, now accepting the 3-rung VK ladder. Net +1 VK.

Stacked on #24612 (spl/a-1375-msgs-only-block).

Two transitional decisions (dev-only; closed by the future Fast Inbox flip)

• in_hash unconstrained pass-through. The circuit no longer builds the sha256 frontier tree. in_hash stays in the parity public inputs as an unconstrained hint — the orchestrator supplies the true frontier root via computeInHashFromL1ToL2Messages, the circuit echoes it out, and the checkpoint root copies it into the header. L1's require(header.inHash == inbox.consume()) still passes, so no L1 changes (ConstantsGen.sol regenerates byte-identical to the base).
• Sponge real-count decoupling. Block roots absorb the message sponge at the real count while the L1-to-L2 tree insert stays a padded fixed subtree, via a new L1ToL2MessageBundle { messages, num_msgs, num_real_msgs } struct so the real count can be dropped later with minimal change. num_msgs is not otherwise pinned in-circuit — documented as a dev-mode gap backstopped by the L1 pending-chain header hash, parallel to in_hash.

Scope

Threads the single sized proof through the orchestrator, bb-prover, proving broker, and TS bindings — collapsing getBaseParityProof/getRootParityProof into getInboxParityProof and PARITY_BASE/PARITY_ROOT into one INBOX_PARITY request type. The UltraHonk parity benchmark and bb.js debug test move to InboxParity256.

Validation

• rollup_lib nargo suite: 387/387 passing.
• Reviewed by a second model (Fable) and codex sol; their build-break and consistency findings are folded in.
• Full yarn build, VK/artifact regen, real proofs, and e2e run in CI (blocked locally by a bb write_vk memory-arena OOM on the unchanged rollup_root circuit).

Known follow-up (out of scope, pre-existing on base)

inbox_rolling_hash.nr's doc comment claims the sha256 chain "matches the L1 Inbox," but Inbox.sol accumulates bytes16(keccak256(...)). Harmless today (the rolling hash isn't validated on L1), but the comment should be corrected on the base branch.