fix: pin getAttesters reads to a single L1 block (A-819)

[PhilWindle]

Fixes A-819 (Audit #164).

Problem

RollupContract.getAttesters (yarn-project/ethereum/src/contracts/rollup.ts) made several sequential RPC reads with no pinned block:

• getActiveAttesterCount() (read at latest)
• N chunked getAttestersFromIndicesAtTime(...) reads, one per 1000 indices (each read at latest)

The ts timestamp argument was already captured once and reused consistently across chunks, so the literal "stale timestamp across chunks" framing of the title doesn't occur. The real defect is that the reads are not pinned to a single L1 block: across a block boundary or reorg, the count and the individual chunk reads can observe different attester sets, yielding an inconsistent or truncated result. This only bites for attester sets larger than the 1000-entry chunk size, read precisely across a set-changing block — hence low impact, but real.

Fix

Fetch the current block once in getAttesters, then thread its number as a blockNumber option through getActiveAttesterCount and every chunked getAttestersFromIndicesAtTime read so they all evaluate against the same L1 block. This follows the existing checkBlockTag(options?.blockNumber, ...) pattern already used by many reads in rollup.ts (e.g. getCheckpointNumber, status, canPruneAtTime).

• getActiveAttesterCount and GSEContract.getAttestersFromIndicesAtTime now accept an optional { blockNumber }.

Testing

Verified the full TypeScript build passes. No automated test added: reproducing the block-drift race deterministically would require anvil plus a hook to advance an L1 block between the count read and the chunk reads (or deep viem-client mocking), which isn't justified for this low-impact, pattern-following change. The block-pinning behavior mirrors other pinned reads in the same file.