fix(test): reliably find target proposer in sentinel_status_slash (A-1217)

[PhilWindle]

Problem

The e2e helper warpToSlotBeforeTargetProposer (in sentinel_status_slash.parallel.test.ts) intermittently threw Target proposer ... not found with sufficient buffer within 20 epochs, surfacing as an e2e_p2p flake. It's a deterministic helper bug, not network flakiness.

The search window was derived as searchStart = currentSlot + minBufferSlots, searchEnd = (currentEpoch + 2) * AZTEC_EPOCH_DURATION - 1. With AZTEC_EPOCH_DURATION = 2 and minBufferSlots = 2, the buffer offset consumes a full epoch, so whenever currentSlot is odd the window collapses to a single, always-odd slot. Because the proposer for each slot is a different RANDAO-shuffled committee member, probing only odd slots never examines the even slot of any epoch — where the 1-of-6 target can be the proposer — so the loop exhausts all attempts and throws.

Log verification

Confirmed against CI run cc8c935bb167ed37:

• All 20 attempts probed a 1-slot window, every probed slot odd: 13, 15, 17, … 51. Zero hit lines.
• The target 0x90f79b… was on the committee every epoch (RANDAO-shuffled into different positions) and attested at slots 11–12 — reachable, just never at a probed (odd) slot.
• Zero EpochNotStable reverts during the scan — the search ran clean, just structurally blind to even slots.

Fix

Extract the proposer search into a shared findUpcomingProposerSlot in e2e_p2p/shared.ts, parameterized by minLeadSlots, and have the sentinel test use it:

• Scans forward one slot at a time from currentSlot + minLeadSlots, so it examines both epoch parities (fixing the odd-only blindness) and finds the RANDAO-shuffled target wherever it proposes.
• Guarantees the returned slot is at least minLeadSlots ahead, so the sentinel can warp to targetSlot - minLeadSlots for its settle buffer with no risk of a backwards warp — the lead comes from the scan start, not from a per-epoch position constraint.
• Handles EpochNotStable by warping one epoch forward and continuing, keeping the lead.

The sentinel helper becomes a thin wrapper: findUpcomingProposerSlot({ minLeadSlots: 2 }) then advanceToSlot(targetSlot - 2).

Kept separate from the existing advanceToEpochBeforeProposer, which serves a genuinely different pattern: its four callers stay one epoch before the target to start sequencers, then warp to the epoch boundary, and rely on warmupSlots for their warm-up margin (load-bearing — without it their proposals serialize past the slot boundary and are rejected as late). That helper is unchanged, so its callers are unaffected.

Testing

• Build, format, and lint clean; only shared.ts and the sentinel test changed.
• The proposer search now examines both parities and guarantees the lead by construction.
• Not yet run: the full e2e (sentinel_status_slash.parallel.test.ts, ~20 min, real-time-dependent). The real validation is running it repeatedly to confirm the proposer is found and the suite's other two tests (which share the helper) still pass.

Closes A-1217.

[AztecBot]

Flakey Tests

🤖 says: This CI run detected 2 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (8;;http://ci.aztec-labs.com/f4f8e30e112388c8�f4f8e30e112388c88;;�): yarn-project/kv-store/scripts/run_test.sh src/bench/sqlite-opfs-encrypted/map_bench.test.ts (1s) (code: 0)
\033FLAKED\033 (8;;http://ci.aztec-labs.com/7d7cf097f2b0014d�7d7cf097f2b0014d8;;�): yarn-project/kv-store/scripts/run_test.sh src/sqlite-opfs/internal/ordered-binary-browser.test.ts (1s) (code: 0)