fix(e2e): resolve flaky checkpoint TypeError in multi_validator_node test (#24543)

## Flake

`multi-node/block-production/multi_validator_node.parallel.test.ts`,
case "should build blocks & attest with multiple validator keys", failed
on [#24537](#24537)
(unrelated PR) with:

```
TypeError: Cannot read properties of undefined (reading 'checkpoint')
    at checkpoint (multi-node/block-production/multi_validator_node.parallel.test.ts:92:73)
```

CI log: http://ci.aztec-labs.com/0f321ffb9fa923af

## Root cause

`deployContractAndGetAttestedCheckpoint` reads the published checkpoint
from the archiver immediately after the deploy tx receipt turns mined:

```ts
const [publishedCheckpoint] = await dataStore.getCheckpoints({ from: blockData!.checkpointNumber, limit: 1 });
const payload = ConsensusPayload.fromCheckpoint(publishedCheckpoint.checkpoint, ...); // undefined here
```

The receipt turns mined as soon as the block is built locally, but the
archiver only stores the *published* checkpoint (with its attestations,
which come from the L1 `propose` calldata) once its L1 sync downloads
that tx. In the window between the two, `getCheckpoints` returns `[]`
and `publishedCheckpoint` is `undefined`.

The CI log shows the race directly: the test node published checkpoint 1
to L1 at `15:17:57.694` (`sequencer:publisher ... Published checkpoint 1
at slot 14`), and its archiver logged `Downloaded checkpoint 1` at
`15:17:57.795` — by which point the test had already failed and teardown
was running.

This is a test-side race, not a production bug: the archiver API is
behaving as documented for a not-yet-synced checkpoint.

## Fix

Poll for the checkpoint with `retryUntil` instead of reading it once,
mirroring the existing pattern in
`single-node/cross-chain/cross_chain_messaging_test.ts`
(`advanceToEpochProven`), which wraps the same lookup in
`retryUntil(..., 'archiver indexes checkpoint N', 120, 0.5)`.

Note: the `next`-line variant of this test
(`e2e_multi_validator/e2e_multi_validator_node.test.ts`) has the same
unguarded lookup in two places and could flake the same way; that file
is on a different base branch, so it is not touched here.

Based on `merge-train/spartan-v5` because the flaking file only exists
on the v5 line (it was consolidated into `multi-node/` there), and the
failing run was on a PR targeting that branch.

---
*Created by
[claudebox](https://claudebox.work/v2/sessions/0959caa9f03f59fa) ·
group: `slackbot`*

Author: AztecBot

yarn-project/end-to-end/src/multi-node/block-production/multi_validator_node.parallel.test.ts

@@ -6,6 +6,7 @@ import { Fr } from '@aztec/aztec.js/fields';
 import { createExtendedL1Client } from '@aztec/ethereum/client';
 import { BlockNumber, EpochNumber } from '@aztec/foundation/branded-types';
 import { Signature } from '@aztec/foundation/eth-signature';
+import { retryUntil } from '@aztec/foundation/retry';
 import { RollupAbi } from '@aztec/l1-artifacts/RollupAbi';
 import { StatefulTestContractArtifact } from '@aztec/noir-test-contracts.js/StatefulTest';
 import { CheckpointAttestation, ConsensusPayload } from '@aztec/stdlib/p2p';
@@ -84,7 +85,14 @@ describe('multi-node/block-production/multi_validator_node', () => {
 
     const dataStore = validatorNode.getBlockSource() as Archiver;
     const blockData = await dataStore.getBlockData({ number: BlockNumber(tx.blockNumber!) });
-    const [publishedCheckpoint] = await dataStore.getCheckpoints({ from: blockData!.checkpointNumber, limit: 1 });
+    // The receipt turns mined as soon as the block is built locally, but the archiver only stores the
+    // published checkpoint (with its attestations) once it syncs the L1 propose tx, so poll for it.
+    const publishedCheckpoint = await retryUntil(
+      async () => (await dataStore.getCheckpoints({ from: blockData!.checkpointNumber, limit: 1 }))[0],
+      `archiver indexes checkpoint ${blockData!.checkpointNumber}`,
+      120,
+      0.5,
+    );
     const signatureContext = {
       chainId: config.l1ChainId,
       rollupAddress: deployL1ContractsValues.l1ContractAddresses.rollupAddress,