refactor(stark): compute OOD pruning layout once and thread it through verify

[MauroToscano]

What

PR #823 added g·z OOD trace-opening pruning. The layout metadata and the full-grid reconstruction were then derived redundantly across several sites that had to be kept in lockstep by hand. This PR bundles that layout into one ood::OodLayout struct, builds it once per proof, and threads borrows through verify — no behavior change, strictly less work.

Rebased onto the current feat/logup-acc-current-row, which now composes #835 (the standalone ood_blocks_well_formed shape guard, also run in the Phase A loop) and #826 (the fused per-FRI-point deep-composition reconstruction: reconstruct_deep_composition_poly_evaluation_pair + the hoisted compute_query_invariant_deep_terms, which take next_row_cols indices rather than bool flags).

The duplicated sites (before)

• num_eval_points + next_row_cols, then num_surviving_trace_openings / build_pruned_trace_term_coeffs, recomputed in:
  • verifier::replay_rounds_after_round_1 (round-4 transcript replay)
  • prover round-4 (round_4_compute_and_run_fri_on_the_deep_composition_polynomial)
• reconstruct_ood_full built twice per verify — once in step_2 (after the ood_blocks_well_formed guard) and again, unguarded, in step_3, which silently relied on step_2/Phase A having validated the block shapes first.
• split_ood_blocks args recomputed in prover round-3.

Why compute-once

• Drift risk: independent copies of the same AIR-metadata expression (transition_offsets.len() * step_size, trace_columns, the next-row column set) must stay bit-identical for Fiat-Shamir to line up between prover and verifier. One source removes that footgun.
• Hidden ordering dependency: step_3's reconstruction had no shape guard of its own; it was only safe because step_2/Phase A ran first. Hoisting the guard + reconstruction into the caller makes that ordering explicit.
• Minor guest-cycle saving: the verifier now reconstructs the full OOD grid once and shares it with both steps, instead of twice. (Relevant for the in-VM recursion verifier.)

How

• New ood::OodLayout holds the AIR-derived layout (num_total_cols, num_eval_points, step_size, next_row_cols) and forwards to the existing free functions via num_surviving(), flags(grid_width), build_trace_term_coeffs(), split_full(), reconstruct_full(), plus expected_next_width()/expected_next_height() and next_row_cols()/step_size() accessors. The free functions and their pub API are untouched; the struct only wraps them and adds no new arithmetic. It stays decoupled from the AIR trait — a one-line ood_layout helper per crate reads the four raw values and calls OodLayout::new.
• verify_rounds_2_to_4 builds the layout, runs ood_blocks_well_formed, and reconstructs the grid once, then passes &ood_full / layout.step_size() into step_2 and &ood_full / layout.next_row_cols() / layout.step_size() into step_3. The guard keeps the same check, the same return false semantics, the same "Composition Polynomial verification failed" log on failure, and the same order relative to grinding.
• Transcript-replay and both prover sites now derive from the same struct.

Signature changes (all internal trait methods, single caller each)

• step_2_verify_claimed_composition_polynomial(..) gains ood_full: &Table<FieldExtension>, step_size: usize.
• step_3_verify_fri(..) gains ood_full: &Table<FieldExtension>, next_row_cols: &[usize], step_size: usize (extends the precedent perf(stark): fuse and hoist deep-composition reconstruction for both FRI points #826 set, which threaded these into the fused reconstruction).
• replay_rounds_after_round_1(..) gains layout: &ood::OodLayout.
• New IsStarkVerifier::ood_layout and IsStarkProver::ood_layout helpers.

ood_blocks_well_formed left as-is (deliberate)

#835's guard also computes expected next-block dims from AIR metadata. Its width check uses trace_layout().0 + num_auxiliary_rap_columns() — and num_auxiliary_rap_columns() is an overridable trait method I cannot prove always equals trace_columns (OodLayout::num_total_cols). So a full fold onto OodLayout is not provably behavior-preserving, and a partial fold (layout dims + air width) would force a layout construction in the Phase A hot loop for no net simplification. The expected_next_width/expected_next_height methods exist on OodLayout for the verify path; the guard keeps its own inline computation.

Zero behavior change + validation

• Fiat-Shamir absorption/sampling order is untouched; the metadata sites keep using trace_columns.
• The DEEP reconstruction keeps reading next_row_cols on the reconstructed grid exactly as before.
• The verifier gains no new asserts/unwraps/panics and every existing return false path is preserved; net work strictly decreases (one reconstruction instead of two, no added allocations).
• cargo test --release -p stark: 196 passed, 0 failed (includes a new OodLayout-delegates-to-free-functions test locking the wrappers to the free functions).
• make lint (fmt --check + all four clippy passes incl. cuda features): exit 0.

Stacking

Stacked on feat/logup-acc-current-row (the open #823 branch, into which #833 and #835 have merged); base will auto-retarget to main when #823 merges.