feat(validator): verify a checkpoint's final Inbox endpoint against L1 before accepting a proposal

[spalladino]

Background

The L1 Inbox is an ordered log of messages sent from Ethereum to Aztec. It groups messages into buckets held in a
bounded on-chain ring; a bucket endpoint is the cumulative message count at the end of one such bucket, and its
rolling hash commits to every message through that count. A checkpoint may end its intermediate blocks at arbitrary
message prefixes, but the completed checkpoint must end at a live bucket endpoint. Once accepted locally, a
checkpoint can become the optimistic parent on which a node prepares the next slot.

The problem

Nothing is known to be broken under the existing design: proposers already resolve an endpoint while building and
run a publication preflight, while L1 ultimately enforces the rule. This PR deliberately adds an independent
acceptance policy to every receiving node.

The endpoint unit test uses a live ring containing these entries:

1. Bucket sequence 7 ends at message total 200 and commits to rolling hash H200.
2. Bucket sequence 8 ends at message total 400 and commits to rolling hash H400.
3. A checkpoint ending at 200 and signing H200 is publishable with respect to this rule.
4. For an upper bound of 256, the Inbox resolver returns the closest endpoint at or below it: 200. Because
   200 != 256, total 256 is an interior position between the endpoints at 200 and 400, not a bucket boundary.
5. A checkpoint ending at 200 but signing a hash other than H200 also fails: the count is a boundary, but it
   commits to different message content.

Previously, a proposal ending at 256 could pass checkpoint-content validation if its blocks and locally available
messages were internally consistent. A node could then accept it as its optimistic parent, and a committee member
could attest to it, without independently confirming the endpoint against L1. Such a checkpoint would still fail
the L1 boundary rule at publication. The new policy avoids building or attesting on that unconfirmed endpoint.

What this changes

After deterministic checkpoint validation succeeds, every receiving node reads the final consumed message count
from the authenticated last block and pairs it with the rolling hash in the signed checkpoint header. It does not
trust an unsigned bucket hint from the proposer.

The node then:

1. Reads the L1 head's number and hash.
2. Pins getBucketAtOrBeforeTotal to that block number.
3. Re-reads the block at the same height and requires the hash to be unchanged.
4. Accepts only an exact message-total match with the signed rolling hash.

The step is retried for up to two seconds, capped by the remaining per-slot duty budget. Content validation remains
cached, but this L1 check is not: the attestation path rechecks a fresh view before reusing a cached valid result.
The all-nodes callback completes this validation before the proposal can become the local optimistic parent.

An unreadable or replaced view is reported separately from a readable non-match. Both refuse validation but cause
no slashing, invalid-proposal marker, or peer penalty.

A refusal must also stay off the proposer's record. It is this node's failure to check, not the proposer's to answer
for: the bucket ring, the local provider and L1 itself all move independently of the moment the checkpoint was signed.
So a refusal records the unverifiable outcome introduced below this PR (in #25440), which the sentinel surfaces as
checkpoint-unverifiable and counts in neither half of the missed-proposal rate. Recording nothing would have been
worse: with no record and no checkpoint on L1, the sentinel reads the slot as one the proposer never proposed in, and
counts that against them.

Uncertainty also never revises a determination that already exists. A refusal cannot overwrite a valid this node
recorded for the same checkpoint, and — since a proposer may equivocate — it cannot erase an invalid recorded for the
slot from a different proposal either.

What this does not do

This is not evidence of a confirmed security defect in the previous policy, and it does not prove that an accepted
checkpoint will land on L1. A uniformly lagging provider can return a self-consistent stale view that this check
cannot detect. A checkpoint ending at the open current bucket can pass this endpoint check and still fail L1
publication with Rollup__InboxBucketStillMutable; settlement remains outside this gate. A later reorg can also
invalidate the publication assumptions.

The check is not applied to historical archiver ingestion or proving, because the bounded ring may already have
evicted old endpoints. The node that actually built a checkpoint retains its proposer fast path, relying on the
endpoint resolution performed during construction and the later publication preflight. The testing-only skip flag
still permits attestation without validation and records nothing as valid.

Each check costs two block reads and one pinned eth_call. Validators normally incur another set when the
attestation path reuses the cached content verdict.

Testing

Unit tests cover exact endpoints at 200 and 400, the interior position at 256, rolling-hash mismatch, eviction,
genesis at total zero, unreadable responses, unidentified blocks, and replacement of the captured L1 view.
Proposal-handler tests cover arbitrary intermediate prefixes, checkpoints consuming no new messages, bounded
retries, a permanently stalled RPC, cached-content reuse, fresh endpoint checks before attestation, optimistic
parent rejection, and preservation of an earlier valid outcome. Integration fixtures verify dependency wiring.

The L1 behavior is exercised through fake Inbox and client implementations; the diff does not add an end-to-end
test against a live Ethereum RPC or a real reorg.