fix(pxe): UNFINALIZED_TAGGING_INDEXES_WINDOW_LEN should be MAX_PRIVATE_LOGS_PER_TX + headroom, not exactly MAX_PRIVATE_LOGS_PER_TX

[vezenovm]

Summary

Follow-up to #24429. That PR widened UNFINALIZED_TAGGING_INDEXES_WINDOW_LEN from 20 to exactly MAX_PRIVATE_LOGS_PER_TX (64). This PR argues that's still not the right value for the scenario #24429 was trying to fix, and proposes MAX_PRIVATE_LOGS_PER_TX + 20.

Scope note (see "Known limitation" below): this fixes a real, CI-confirmed problem; multiple ordinary pending txs to the same counterparty stacking up before the first is mined. There is a separate, harder problem captured in F-783. Additional separate breakage follow-up on the sender-side when pending logs exceed the window F-784.

Investigation

MAX_PRIVATE_LOGS_PER_TX is a genuine, protocol-enforced bound for ordinary transaction patterns: noir-protocol-circuits constants.nr defines MAX_PRIVATE_LOGS_PER_TX directly as MAX_NOTE_HASHES_PER_TX. A fresh secret's very first ordinary tx can legitimately consume that many indexes before anything is finalized.

But exactly MAX_PRIVATE_LOGS_PER_TX leaves zero headroom for a second unconfirmed tx to the same counterparty once the first one is already near the max. finalized only advances once the sender's own node observes a tx as mined (see syncSenderTaggingIndexes), so any burst of sends to one counterparty before the first is mined can exhaust the window. This is exactly what happened in #24429's bench_build_block failure: #24387's handshake default added extra per-cold-chain overhead, and the bench builds up a backlog of unmined txs by design, so used ran past finalized (which stayed at 0) before window 20 could absorb it.

Confirmed live: reproduced on this branch at bare 20

To settle whether #24429's bump was actually necessary, we reset this branch's constant back to bare 20 and let bench_build_block run to completion in CI rather than relying on the reasoning above alone. It failed the same way (see http://ci.aztec-labs.com/4ed074af4b8ab633 from a4feea1, on the current merge-train/fairies-v5 tip:

ERROR: kv-store:lmdb-v2 pxe-0 Failed to commit transaction: Error: Highest used index 21 is further than window length from the highest finalized index 0.
            Tagging window length 20 is configured too low. Contact the Aztec team
            to increase it!

So this isn't a synthetic worst case: it's a real failure on real CI infrastructure, at index 21, i.e. just one past the window. Not even a large burst of txs.

Red/green evidence

Added sender_tagging_store.test.ts: "allows an ordinary pending tx to stack on a fresh secret already at the MAX_PRIVATE_LOGS_PER_TX floor" — one tx uses the full worst-case 64-log burst from a fresh secret, then a second, ordinary-sized pending tx to the same secret must still be storable before either is mined.

• Red at bare 20: the first call in that test already throws, with zero other txs involved:

  Highest used index 63 is further than window length from the highest finalized index 0.
  Tagging window length 20 is configured too low.
  

• Green at MAX_PRIVATE_LOGS_PER_TX + 20: same scenario passes.

This is the key point for review: the bench_build_block failure isn't just "risky under bursty load".20 is mathematically incapable of tolerating even one legitimate worst-case single ordinary tx, independent of what CI on this branch shows either way. CI passing at 20 only means our current test/bench suite doesn't happen to construct a single tx tagging more than 20 logs to one recipient; it was never testing the general safety of the constant, just this specific workload's exposure to it. The live CI failure above is the same underlying gap, just surfaced through a different, real workload instead of a targeted unit test.

We also added tests to pin the window's stacking semantics: a run of window+1 one-log pending txs to one secret fits, while the next tx throws.

Why + 20, not * 2 or another additive constant

• The floor (MAX_PRIVATE_LOGS_PER_TX) covers one worst-case ordinary tx. The failure mode above is about additional, ordinary-sized pending txs to the same counterparty stacking up, not another maxed-out 64-log tx.
• It's the value the team had already judged sufficient for realistic pending-tx headroom before fix(bench): use address-derived tagging secrets for the client-flows bench; widen the PXE unfinalized tagging window #24429 (it was just misapplied as the entire budget instead of a margin on top of the floor).

[AztecBot]

Flakey Tests

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

\033FLAKED\033 (8;;http://ci.aztec-labs.com/1ca868bf43492353�1ca868bf434923538;;�):  yarn-project/end-to-end/scripts/run_test.sh simple src/single-node/proving/proof_fails.parallel.test.ts "does not allow submitting proof after epoch end" (118s) (code: 0) group:e2e-p2p-epoch-flakes