Benchmark regression workflow reports green without an executable regression decision

[sunt05]

Description

The benchmark suite documents a regression decision that does not exist in code, and the daily Benchmark regression workflow reports green without running any scientific comparison.

Verified at d0f4ce2df:

• run_benchmark.py only asserts that two runs of the same pinned release give a byte-identical fingerprint. Nothing compares a release with the previous one.
• bench_drift.py computes descriptive deltas and says so explicitly ("NOT a reproduction assertion"). No thresholds are defined anywhere under benchmark/.
• Yet the Stage 2 job in .github/workflows/benchmark-regression.yml says "the regression decision vs the previous release is applied here", benchmark/README.md says the full regression "applies the regression decision", and the prep-release skill (step 4) gates a release on "a material increase in any flux" without defining material.
• The workflow's only active job is the synthetic-data supply proof; full-benchmark is if: false (intentionally, pending data-governance sign-off). Scheduled run 34009164672 shows supply-proof success and full-benchmark skipped, so the green badge certifies a secret-to-Zenodo fetch path, not model accuracy.
• The harness's own unit tests under benchmark/tests/ are not run by any workflow or Makefile target.

Impact

A maintainer reading the workflow, README or release checklist believes an executable regression gate exists. In practice the release gate is a manual reading of drift_table.csv with no agreed tolerance, and the CI surface cannot fail on a scientific regression even for the pinned results already committed under benchmark/results/.

Proposed scope

Within existing data authorisation (no enabling of Stage 2, no new data transfers):

1. Add a pure regression decision (benchmark/bench_regression.py) that takes the results index, an explicit committed thresholds file and a (previous, candidate) pair, and returns per-metric pass/fail for both the energy-balance and RSL air-temperature axes.
2. Add a CLI (benchmark/check_regression.py) with a sweep mode over every consecutive release pair in the committed results/index.json and a single-pair mode for the release gate; exit non-zero on a regression and write a derived-statistics-only report.
3. Add an active, secret-free job to the benchmark workflow that runs the pure harness tests and the sweep against the committed pinned results, so the workflow can actually fail on a scientific regression in recorded history and on a broken harness.
4. Make the Stage 2 step call the real gate (still disabled), and rewrite the workflow header, README and release-skill text so they state exactly what the daily green certifies.

Acceptance criteria

• python benchmark/check_regression.py --sweep passes on the committed index and fails when a synthetic index with a material MAE increase is supplied.
• Thresholds live in one committed file with a header explaining how they were calibrated and that they are maintainer-reviewable.
• The benchmark workflow has an active job that exercises the harness tests and the sweep without secrets, and the disabled Stage 2 step invokes the same decision.
• No documentation in the repository claims an automated regression decision beyond what the code performs.
• full-benchmark stays if: false; the remaining dependency (restricted production record, ZENODO_TOKEN, data-owner sign-off) is stated where the job is defined.