feat(fast-inbox): make the inbox message rollback content-aware

[spalladino]

Context

When an L1 reorg touched a block whose Inbox messages the node had already consumed, the archiver rewound the messages from that block on and pruned every proposed block built on them, before it knew what the canonical chain would hand back. An everyday re-mine, where the same transactions land in a replacement block in the same order, therefore cost the proposer its slot even though every leaf and every rolling hash was unchanged and L1 would still have accepted the checkpoint.

Approach

The rollback now fetches the canonical messages before it writes anything, compares them against what it holds, and commits the swap in a single transaction.

• The fetch runs in the same whole-L1-block batches the regular retrieval uses and stops at the first batch that reaches the last index the node holds, so a node that fell far behind an orphaned bucket does not pull everything since into one transaction. It waits for a bucket that spans co-timestamped L1 blocks to close before stopping, and checks every batch tail against the live chain, the final one included. A failed check writes nothing.
• Equal rolling hashes at an index mean equal leaves through it, so one walk finds the lowest index the canonical chain no longer backs: either its leaf changed, or it closed a bucket that the canonical chain now carries on past, which takes away a boundary a block ended on. Leaves, bucket snapshots and proposed blocks are then dropped only from there. A re-mine that keeps the partition drops nothing and only rewrites the bucket metadata derived from the L1 block; a bucket whose tail was replaced keeps the blocks that stopped below the replaced leaf; a split only adds a boundary no block ever used, so it drops nothing either.
• The swap, the snapshot rewrite, the sync point and the proposed-chain prune commit together, and the finalized marker is never advanced past the sync point the swap commits.
• Before publishing, the proposer checks that its own archiver still holds the checkpoint's last block under the hash it was built with. The end-of-slot prune and the prune on conflict with a checkpoint seen on L1 can still take those blocks while attestations are collected, and publishing them would put a checkpoint on L1 that the node cannot serve. A node configured not to push its proposed blocks skips the check.

Stacked on #25361

Fixes A-1907