test(spartan): wait for proposed instead of checkpointed in performTransfers (#23853)

## What

`performTransfers` (used by the spartan reorg scenario and other spartan
load tests) waits for each transfer to reach `TxStatus.CHECKPOINTED`
before starting the next round. That is the default of `waitForTx`
(`aztec.js/src/utils/node.ts`: `opts?.waitForStatus ??
TxStatus.CHECKPOINTED`), inherited because the call passed only
`timeout`.

This makes it pass `waitForStatus: TxStatus.PROPOSED` instead, so each
round only blocks until the tx is included in a proposed block, not
until that block is checkpointed.

```ts
await Promise.all(provenTxs.map(t => t.send({ wait: { timeout: 600, waitForStatus: TxStatus.PROPOSED } })));
```

## Why

The `v6.0.0-nightly.20260604` nightly Spartan Scenario (set 1) failed
when `reorg.test.ts › survives a reorg` hit its 210-min Jest timeout. It
was not a chain failure — the chain was healthy and processing transfers
the whole time, just slowly.

Comparing against the last passing nightly (`v6.0.0-nightly.20260602`),
each transfer round in `performTransfers` went from ~35s (≈1 slot) to
~77s (≈2 slots), doubling both 64-round transfer loops (~38min → ~82min
each) and pushing the test from ~140min to over its 210-min budget.
Slot/epoch cadence was unchanged (the fixed 3-epoch sleep was identical,
~57.6min, both days), so the extra time is the growing lag between a tx
being **proposed** and being **checkpointed**.

These load loops only need the chain to keep accepting transactions; the
reorg test's assertions check pending/proven tips independently via
`RollupCheatCodes`. Waiting for `PROPOSED` is sufficient and removes the
dependency on checkpoint-sealing latency, restoring the previous
per-round timing.

## Scope / notes

- `performTransfers` is shared by several spartan scenario tests; all
use it purely as load generation, so the relaxed wait applies to all of
them.
- This is a test-side mitigation. The underlying regression — checkpoint
build/seal lag growing ~1 slot per tx somewhere in the `1f6248d…4adc0f8`
window — is separate and still worth investigating (see the `Error
building checkpoint … messages not yet sealed` log lines).
- Not runnable locally (spartan/k8s e2e); validation is via the nightly
scenario run / CI.

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

Author: PhilWindle

yarn-project/end-to-end/src/spartan/setup_test_wallets.ts

@@ -15,6 +15,7 @@ import type { Logger } from '@aztec/foundation/log';
 import { makeBackoff, retry, retryUntil } from '@aztec/foundation/retry';
 import { TokenContract } from '@aztec/noir-contracts.js/Token';
 import type { AztecNodeAdmin } from '@aztec/stdlib/interfaces/client';
+import { TxStatus } from '@aztec/stdlib/tx';
 import { registerInitialLocalNetworkAccountsInWallet } from '@aztec/wallets/testing';
 
 import { getACVMConfig } from '../fixtures/get_acvm_config.js';
@@ -426,7 +427,9 @@ export async function performTransfers({
 
     const provenTxs = await Promise.all(txs);
 
-    await Promise.all(provenTxs.map(t => t.send({ wait: { timeout: 600 } })));
+    // Wait only for the txs to be proposed, not checkpointed. This is enough to keep the chain
+    // loaded for the reorg scenario, and avoids each round blocking on the (slower) checkpoint lag.
+    await Promise.all(provenTxs.map(t => t.send({ wait: { timeout: 600, waitForStatus: TxStatus.PROPOSED } })));
 
     logger.info(`Completed round ${i + 1} / ${rounds}`);
   }