test(ci): mark e2e_expiration_timestamp invalidates-setup race as flake

[AztecBot]

Why

PR #23344 (merge-train/spartan) was dequeued after the heavy merge-queue grind failed on e2e_expiration_timestamp.test.ts:

e2e_expiration_timestamp › when requesting expiration timestamp lower than the next block › with an enqueued public call › invalidates the transaction

Block header not found in invalidates-the-transaction setup (thrown at line 147, after 2 ms)

Failing log: http://ci.aztec-labs.com/a8a7ea45ecd3fe2b · Run: https://github.com/AztecProtocol/aztec-packages/actions/runs/26115610676

Root cause

The test was migrated to PIPELINING_SETUP_OPTS in #23275. The describe-level beforeEach calls aztecNode.getBlockData('latest') successfully, then runInvalidatesTest calls it again a few ms later. The previous runInvalidatesTest invocation warped L1 time ~72s ahead, briefly pushing the archiver/world-state into a reorg window where there is no "latest" block. The second fetch lands in that window and returns undefined, so the test throws before doing any real work.

The first runInvalidatesTest (no enqueued public call) passes because the warp hasn't happened yet; only the second one (with enqueued public call) races against it. The sequencer also reports Transaction sending is interrupted / Checkpoint publish failed for slot 10 in the same window, which corroborates the warp disturbance.

Fix

Add a flake entry scoped tightly to the specific thrown message. Other failures in the same test still fail the build. Owner is palla (author of #23275).

A proper fix would either reuse the header captured in beforeEach or retry getBlockData('latest') with a short backoff in runInvalidatesTest. Out of scope here — left to the test owner.

Full analysis: https://gist.github.com/AztecBot/95ea96c0fbf8f2af49d76555b291c46d

ClaudeBox log: https://claudebox.work/s/925ef806f9078a26?run=1