fix(sequencer): reserve blob space for a transaction-less checkpoint tail block

[spalladino]

Background

The L1 Inbox stores messages sent from Ethereum to Aztec and groups them into buckets. A checkpoint may consume
messages incrementally across several L2 blocks, but its final message count must equal the end of a live Inbox
bucket before the checkpoint can be published. If the scheduled block-building sub-slots finish before that
boundary is reached, the proposer can add a transaction-less tail block that consumes the remaining messages.

The problem

A transaction-less block still serializes block-end metadata into the checkpoint's blobs. The existing packing
calculation reserved space for the block currently being built, but not for a possible tail block.

The test captures the failure with the protocol's actual blob geometry:

1. A checkpoint has six blobs of 4,096 fields, for 24,576 fields in total. Its one-field checkpoint-end marker
   leaves 24,575 fields for blocks.
2. A transaction-less block serializes to seven fields, or 224 bytes.
3. Suppose the existing block has used 24,551 fields and the checkpoint may still contain two more blocks.
4. The old calculation reserved seven fields for the current block and offered the remaining 17 fields to its
   transactions: 24,575 - 24,551 - 7 = 17.
5. If those 17 fields are used, the current block brings usage to 24,575. If message consumption then stops at a
   prefix that is not a live bucket endpoint, the required seven-field tail no longer fits.
6. The proposer cannot produce a publishable checkpoint and loses the slot, even though omitting seven transaction
   fields would have left enough blob capacity for the tail.

What this changes

While another block can still follow, proposer-side packing now reserves two sets of block-end fields: seven for
the block being built and seven for a possible transaction-less tail. In the example, the transaction allowance is
therefore 10 fields:

24,575 - 24,551 - 7 - 7 = 10

After using those 10 fields and writing the current block's seven fields, exactly seven fields remain. A real tail
block can consume that reservation, bringing block data to 24,575 fields; the separately accounted checkpoint-end
marker brings the encoded checkpoint to the full 24,576-field capacity.

The reservation is released when building the last block the checkpoint is allowed to contain, because no tail can
follow it. The transaction allowance is also floored at zero when the available capacity is smaller than the
required overhead.

What this does not do

This changes only the local proposer's transaction-packing policy. A validator re-executing another node's proposal
does not apply the reservation, so the change cannot make an otherwise valid peer proposal fail validation.

The reservation protects blob capacity only. It does not reserve execution time, guarantee that the tail can be
built before the duty ends, or make an unavailable Inbox endpoint reachable. It does not change message limits,
per-block limits, the maximum checkpoint block count, checkpoint timing, or total blob capacity.

Testing

Unit tests serialize a real transaction-less L2Block and pin its size at seven fields and 224 bytes. They cover
near-capacity packing, the exact-fit case, being one field short, a zero transaction allowance, releasing the
reservation on the last possible block, consuming it with a real tail, and counting the checkpoint-end marker only
once. A separate case confirms that validator re-execution does not reserve tail space.

The tests exercise checkpoint-builder accounting; they do not simulate the full timed proposer flow or prove that
an extra block can always finish within the slot.