fix(bb): round virtual_size up to even in Polynomial::allocate_backing_memory

[AztecBot]

Summary

Fix the failing nightly debug build (https://github.com/AztecProtocol/aztec-packages/actions/runs/24923818366). On next, every variant of HonkRecursionConstraintTestWithoutPredicate.GenerateVKFromConstraints trips the index < virtual_size_ + virtual_padding debug assertion in SharedShiftedVirtualZeroesArray::get during the first sumcheck round.

Root cause

OinkProver::commit_to_masking_poly allocates gemini_masking_poly with virtual_size = polynomials.max_end_index(), which can be odd for small/sparse circuits. Sumcheck's extend_edges and partially_evaluate then read pairs (poly[i], poly[i+1]) up to round sizes derived from the active region rounded up to even, so when i + 1 == virtual_size the trailing read lands past the polynomial's virtual zeroes and trips the debug assertion. Release builds quietly read out-of-bounds zero memory and pass.

This started failing in the 2026-04-22 nightly (commit 63c67a0f44…), the first run after PR #22334 (chore!: masking at the top of the trace) which made committed polynomials extend to max_end_index() rather than dyadic_size.

Fix

Round virtual_size up to the next even value inside Polynomial::allocate_backing_memory. This bakes the even-virtual-size invariant that sumcheck's hot loops already rely on into the polynomial machinery itself, so the loops can stay branch-free and every Polynomial<Fr> constructed through the standard ctors (including Polynomial::random(odd_size)) automatically satisfies it.

Per Sergei's review feedback on the closed PR #22788 / #22790 attempts: rather than gating every call site (extend_edges, partially_evaluate) or papering over a single allocation site (gemini_masking_poly), the invariant lives where polynomials are built.

The change is allocation-only — actual backing memory size is unchanged; only the virtual_size_ field stored on SharedShiftedVirtualZeroesArray is bumped by 1 when the requested value is odd. All current callers either pass a power-of-2 (already even) or pass max_end_index() (the case this fix unblocks), so no other code paths change behaviour.

Tests

Run in debug (cmake --preset debug):

• The originally failing HonkRecursionConstraintTestWithoutPredicate/1.GenerateVKFromConstraints reproduces without the fix and passes with it.
• Full polynomials_tests (70/70), sumcheck_tests (29/31, 2 unrelated skips), and ultra_honk_tests (287/287, 8 unrelated skips) still pass.
• HonkRecursionConstraintTestWithoutPredicate/{0,1,2} (GenerateVKFromConstraints + Tampering) all pass; remaining variants {3,4,5} are still running locally and will be confirmed in CI.

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

[AztecBot]

Automatically closing this stale claudebox draft PR (no updates for 5+ days). Re-open if still needed.