bench(whir): model open-phase prover cost (sumcheck + batching) on the left axis

[camofu]

Summary

The left-panel x-axis ("theoretical proxy") was total committed oracle length — a commit-phase-only cost. It prices the codeword FFTs + Merkle hashing but charges nothing for WHIR's open phase: the per-round sumcheck and the cost of batching the opened claims. That omission is exactly why the proxy panel disagreed with the measured wall-clock (and the source of the recent discussion with @WizardOfMenlo about the proxy being "weird" and WHIR looking "too slow").

This replaces the raw oracle-length axis with a modelled prover cost that includes those terms.

What changed

The left panel's x is now a modelled prover cost in base-field multiply-equivalents = sum of, per committed codeword:

• encode (FFT) — with the log N factor and an extension-field-multiply weight (~d²). WHIR re-encodes every round; FRI does one input LDE and then folds for free (no per-round FFT).
• Merkle hash — leaf-hash + compression count (N + N/L), so "fat leaves ⇒ fewer Merkle nodes" is visible.

plus the open-phase terms the old proxy couldn't see:

• sumcheck (WHIR only) — ~2·2^m extension-field multiply-adds over the hypercube. FRI has no analogue.
• batching — forming the combined evaluation constraint.

The raw oracle length is still computed and emitted to the CSV (oracle_len_elems), alongside a new model_cost column.

Effect

With the open-phase terms, the modelled-cost panel now matches the shape of the measured wall-clock panel — FRI owns the cheap-prover corner; WHIR reaches the smallest proofs at higher cost — instead of contradicting it. The divergence the two panels used to show was the sumcheck + batching; now it's modelled rather than hidden.

Caveats (deliberately out of scope)

• The constants (EXT_MUL_COST, PERM_COST, SUMCHECK_DEG) are rough order-of-magnitude values — only the relative shape is meaningful. Calibrating them against a few measured points (cost-model "Step 3") would make the absolute scale trustworthy.
• No per-config parallelism / critical-path model yet (Step 4) — WHIR's sequential rounds vs FRI's embarrassingly-parallel commit. That's why the modelled panel still isn't a perfect predictor of the measured one.
• The batching term uses the structured (shared-suffix) cost of this workload; generic openings would scale it with the claim count.

Notes

Stacked on top of #1 (base carlo/whir-fri-pareto). One file changed (the example); the model lives in whir_build / fri_cost with documented constants near the top.