docs(fast-inbox): document message-prefix consumption and correct the streaming Inbox docs

[spalladino]

Context

The bucketless Fast Inbox rebuild (#25413 → #25414 → #25415) changed what the node does with L1-to-L2 messages: every
L2 block consumes the messages the proposer's archiver has observed, blocks may end at any message prefix, only a
checkpoint's final position must be a live Inbox bucket end (resolved through Inbox.getBucketAtOrBeforeTotal and
preflighted through Rollup.validateCheckpointHeaderAndInbox), validators authenticate content and never penalise a
local prefix disagreement, and the archiver stores a plain message log whose reorg recovery rolls back to the newest
message still on L1 and refetches.

This PR is the normative documentation for that rebuild, plus the documentation errors the review turned up. It
changes prose and comments only — no behaviour, no timing value, no decision gate. The code fixes the review produced
are stacked directly above as #25440, and the three changes that alter node acceptance policy or proposer packing
are above that as #25436, #25437 and #25438, so each can be reviewed and taken or dropped on its own.

Documentation

ethereum-aztec-messaging/inbox.md is rewritten around the current contract: leaf index semantics, the MessageSent
event, a "How messages reach L2" section (immediate greedy consumption, an endpoint lookup only on the final block or
well into the checkpoint, the extra transaction-less block when the schedule runs out, mandatory consumption,
content-only validation), the distinction between public same-block consumption and private consumption against a
historical header, the accepted limitations, ring headroom and back pressure, and the full view-function table. The
portal overview, the aztec-nr messaging guide, the token-bridge, Uniswap and Aave tutorials and the operator glossary
drop the descendant-wait and fixed 12–30 s wording in favour of the readiness helpers.

resources/migration_notes.md gains the umbrella carry-overs, the additive Inbox/Rollup views and errors, the
count-addressed archiver API and the sequencer/validator internals. A new operator page
docs-operate/operators/reference/changelog/v6.md covers the automatic archiver store reset, the lowered
maxBlocksPerCheckpoint floor, the behaviour changes, the non-punitive validator reasons, rollback-and-refetch
recovery and the new L1 views.

Documentation the review found to be wrong

Several comments and pages asserted things the code does not do. Corrected here:

• Recovery was described as comparing content before pruning. It rolls back to an authenticated anchor and refetches.
• The publication preflight's verdict was presented as unconditional, when a due prune pins it to the proven tip.
• Removed selection helpers were still named, and the message-sent log was documented with the wrong shape.
• A comment called four block opportunities "below the Inbox minimum" when four is exactly the floor.
• Range semantics were unstated: CustomRange.end is exclusive, and the archiver's typed range error arrives generic
  across JSON-RPC, so callers must not branch on its class.

No operational timing value was changed anywhere, including in the network defaults, where only the stale
justification comment moved.

Message-count prediction

The largest correction is to what a node promises when it simulates a public call. The count the simulator appends is
an estimate, not a bound in either direction: above the threshold, a checkpoint's final block ends on a live L1 bucket
boundary the simulating node never reads, and that boundary can sit below the local step.

With the consumption cursor at 0, 400 messages observed, and live buckets ending at 200 and 400:

	value
what the local step allows	256
what the final block actually lands on	200

A public call reading message index 220 therefore simulates successfully and then fails when it runs for real. The
prediction mismatch itself is not fixed here (deferred), only described honestly, and waitForL1ToL2MessageReady /
isL1ToL2MessageReady are documented for what they check: inclusion at an L2 tip that already exists, which is a
statement about the chain as it stands rather than a promise about a future block.

Testing

One regression test accompanies the prediction correction — the 200/400 case above, asserting that the local step is
256 while the resolved final-block endpoint is 200. yarn workspace @aztec/sequencer-client test src/sequencer/inbox_message_selection.test.ts passes (18 tests). Nothing else in this PR is executable.

Stacked on #25415 (spl/fi2-bucketless-node-cutover). #25440, #25436, #25437 and #25438 stack above this one.

Part of A-1928

🤖 Generated with Claude Code