chore: regenerate benchmark artifacts only when cost tables drift

[mmagician]

Stacked on #3726. Review the top two commits.

Makes "regenerate only when the drift guard fails" the actual, stated policy. No new enforcement is added — the guard already exists (checked_in_note_costs_match_executed_scenarios). This stops the tooling and the docs from inviting regeneration the guard never asked for.

The sentence that caused the churn

bin/bench-transaction/README.md said a PR that "meaningfully changes cycle counts" must run the target and commit the updated tables, and sold the resulting diff as review signal. That is vague enough to invite regeneration on any cost-affecting change, when the guard only asks past 5%. #3699 regenerated both artifacts for a largest move of BURN at −3.1%, well inside tolerance: 906 lines of generated diff on top of ~250 lines of real change.

Replaced with the policy as it actually stands: feature PRs regenerate nothing, sub-threshold drift is absorbed, and when the guard fails both artifacts are regenerated and committed together.

make update-note-costs → make update-generated

The target regenerates two artifacts but was named for one, which is why contributors ran it for a cost-table refresh and got an 800-line bench-tx.json diff too. Behaviour is unchanged — one run, both artifacts.

Deliberately not split into table-only and snapshot-only targets. Under a both-or-neither policy a split has no purpose, and it would newly make it possible to commit one artifact without the other, a divergence that cannot happen today.

--release is new. The old target ran in debug, which for 43 scenarios each with a trace rebuild is a lot of wall clock for cycle counts that are identical either way.

The two generated table.rs headers are updated in place to match what the renamed generator emits; no constant changes. The one remaining update-note-costs reference in the repo is in the released v0.16.0 CHANGELOG section, left alone as shipped history.

Accepted gap

COMMITTED_SCENARIO_EXPECTATIONS in utils.rs checks padded trace brackets against the committed snapshot, which under this policy lags reality. A change pushing a scenario across a power-of-two padding boundary — a real proving-cost cliff, since proving cost is step-wise in padded trace length — can go unnoticed until a later table drift forces a refresh.

Cycle drift is not a proxy for this: a scenario sitting just under a bracket crosses it on a change far smaller than 5%. In the current snapshot the tightest margins are NETWORK_ACCOUNT_CONFIG at 8,082 of an 8,192 chiplets bracket (1.3% slack), PSWAP partial fill at 32,288 of 32,768 poseidon2 (1.5%), and CLAIM L2-with-fee at 64,045 of 65,536 core/range (2.3%). The window is not hypothetical.

Closing it needs fresh trace data on every PR, which is out of scope here.

Verification

• make test-release: 1886 passed
• make lint clean
• make update-generated runs end to end; make update-note-costs no longer exists
• No-argument cargo run --bin bench-transaction still writes the snapshot and does not touch the cost tables, so miden-vm's documented synthetic-bench workflow keeps working
• Re-running the generator changes only range_rows on 7 scenarios, the run-to-run variance the README already documents

🤖 Generated with Claude Code

https://claude.ai/code/session_01LXcU9HrrmWTCTZTJZnuLSU