test(control): record the slew limiter in the golden corpus

[frahlg]

What this is

A new golden family, slew_limiter, recorded at slew rates a site actually
runs, plus a coverage assertion that fails when the corpus stops covering the
slew limiter. Test-only: no production code moves.

Why

The corpus that landed in #790 is blind exactly where the slew limiter lives.
391 of its 435 records set SlewRateW to 10 kW or 100 kW, against a
control.NewState default of 500 W and a config default of 3000 W. At those
rates no realistic per-tick move reaches the bound, so the limiter is switched
off in all but name. Measured on master before this PR: switching the limiter
off changes only 16 of 435 records by more than 50 W, and 14 of those 16
are incidental — one seeded family that happened to draw a low rate.

That matters more for this clamp than for the others, because the slew limiter
is the last stage in dispatch that can raise a target's magnitude. Every
other clamp shrinks toward zero. It also anchors on the battery's measured
output (SmoothedW) rather than the previous command, so a target of 0 W
becomes ±SlewRateW whenever the battery is not already still.

KNOWN BUG — these records capture today's behaviour, not desired behaviour

The slew/bug_* and slew/blocked_sibling_* records show dispatch commanding
charge on a tick that forbids charging:

passive_arbitrage idle slot, meter -2000 W, battery live +2000 W,
SlewRateW 500 → the site commands +1500 W of charging.

noSelfCharge pins the fleet total to 0 W in dispatch.go; the slew limiter
then re-anchors on the measured +2000 W and walks one 500 W step back toward
it. Nothing downstream floors that: the snap-to-zero carve-out in the slew loop
covers plannerSelfExportSurplusGate and the zero-power manual hold but not
the stale-plan block or the arbitrage-family live-export gate, applyFuseGuard
only shrinks toward zero, floorNegativeTargets is discharge-only, and
planSignIntent returns 0 for an idle slot. The mirror-image leak on the
discharge side is caught, by floorNegativeTargets — the asymmetry is the
bug.

The corpus records behaviour as of this commit, clamps and quirks and all. When
the fix lands, these records move, and the diff is the fix stated in watts.
That is why they are here. The family's doc comment in golden_dump_test.go
says the same thing to whoever reads it next, and the coverage assertion
deliberately asserts the shape of those records (a charge block armed, a live
battery on the charge side, a rate one step cannot cover) and not their watts,
so the fix does not have to argue with the test.

Recorded, verbatim, at 500 W:

bug_no_self_charge_idle_slot_leak_500      grid -2000  live +2000 -> +1500 (clamped)
bug_no_self_charge_stale_plan_leak         grid -1500  live +2500 -> +2000 (clamped)
blocked_sibling_slew_reopens_parked_charge grid -2500  live +2000 -> +1500 (clamped)
carveout_export_surplus_gate_snaps_to_zero grid -1500  live +2500 ->     0

The last line is the same gate with the carve-out in scope: 0 W, no leak. The
difference between those two rows is the whole bug.

What the family covers

155 records — 50 named, 105 seeded from fixed seeds.

• Realistic rates. 250 / 500 / 750 / 1000 / 1500 / 2000 / 3000 W. The
  anchoring records run as a ladder across five of them, so a change to the
  bound itself reads as a clean progression.
• Anchoring. Live output far from target in both directions, plus the
  SlewEnabled=false control pair that says what the tick would have been.
• Reversals across zero, including one negative control where the move is
  small enough that the limiter never binds.
• The charge and discharge blocks with the battery live on the wrong side:
  the bug above, and the discharge side that is floored.
• Fuse pressure against smoothing. forceFuseDischarge runs after the
  limiter for a reason; the recorded relief is 3960 W from the anchor on a
  250 W/tick ramp. Also the per-phase and export-ceiling variants.
• The snap-to-zero carve-out where it applies and, on an otherwise
  identical tick, where it does not.
• The post-slew re-clamp, driver limits and MaxCommandW.
• Fleets — the limiter is per driver, so blocked, offline, priority and
  weighted siblings each get a record.

The coverage gate

TestGoldenCorpusCoverage now replays every record twice, once as recorded and
once with SlewEnabled=false, and counts the records where the answer moves by
more than 50 W. SlewEnabled=false skips exactly the ramp clamp and nothing
else, so the difference is the limiter's contribution after every downstream
stage has had its say — which is why it is measured rather than stored. A
record where the limiter binds and forceFuseDischarge then overwrites it does
not count, and should not.

slew coverage: 123 records bind (>50 W), 123 of them at a production-realistic
rate (<= 3000 W/tick); largest effect 6345 W on slew/seeded_034_priority

The floor is 60. Doctoring the new family's rates back to 100 kW — the #790
blindness, reproduced — drops the count to 16 and fails:

coverage gap: only 16 records where the slew limiter binds by more than 50 W,
want at least 60. A corpus recorded at unreachable slew rates cannot see the
limiter at all — re-record the slew_limiter family.
slew/bug_no_self_charge_idle_slot_leak_500 no longer exercises the leak: live
battery 2000 W is within one 100000 W step, so the limiter reaches 0 W anyway

Verification

Rebased onto #801, which pins the golden scenario clock, and the family
re-recorded through that seam at 8fe82e4. It was first recorded before the
seam, so its energy-path targets still carried wall-clock jitter; the other
seven families keep their earlier recordings, which is why the 0.01 W tolerance
stays.

• Re-recording changes no behaviour. Comparing the two recordings record by
  record: no clamp attribution, flag or driver set differs. 26 numeric values
  in 9 records move, every one of them a planner mode on the energy path, the
  largest by 4.5e-06 W — three orders of magnitude under the tolerance.
  Nothing moved by more than 0.01 W.

• The bug records are unchanged. bug_no_self_charge_idle_slot_leak_500
  still commands +1500 W of charging on a tick that forbids it,
  bug_no_self_charge_stale_plan_leak +2000 W,
  blocked_sibling_slew_reopens_parked_charge +1500 W on ferroamp and +500 W
  on its sibling, and the A/B partner
  carveout_export_surplus_gate_snaps_to_zero still lands at 0 W on the same
  shape.

• Deterministic. All 155 records replay clean, -count=3 and under
  -race. Three fresh recordings differ by at most 6e-14 W, from the order
  the recorder sums per-driver targets before sorting them — the same residual
  the seven older families carry, and not what the tolerance is for. Before the
  seam the family drifted by ~1e-5 W run to run.

• Coverage holds. slew coverage: 123 records bind (>50 W), 123 of them at a production-realistic rate (<= 3000 W/tick); largest effect 6345 W on slew/seeded_034_priority.

• The gate still bites. Two perturbations against the re-recorded corpus,
  both reverted:

  1. Slew bound loosened 10% (sign*SlewRateW → sign*SlewRateW*1.1).
     105 of 590 records flagged — 91 of them in the new family, 14 in the
     old corpus. Diff reads, per record: ferroamp: was +2750.00 W, now +2725.00 W (moved -25.00 W).

  2. The family's rates doctored back to 100 kW — the test(control): golden regression corpus for ComputeDispatch #790 blindness,
     reproduced. assertGoldenSlewCoverage fails and names what was lost:

     slew/bug_no_self_charge_idle_slot_leak_500 no longer exercises the leak:
     live battery 2000 W is within one 100000 W step, so the limiter reaches
     0 W anyway
     coverage gap: only 16 records where the slew limiter binds by more than
     50 W, want at least 60.
     

• make verify clean.

Notes for review

• The family file was recorded with FTW_GOLDEN_OUT and copied in, so the
  other seven families are untouched — a full re-record would rewrite their
  ftw_commit and jitter their energy-path magnitudes for no reason.
  Regeneration is still the one documented command.
• Because this family was recorded after the rest, its ftw_commit is later
  than theirs. The corpus header used to name one commit for the whole corpus;
  it now points at each file's own.
• No changeset: test-only, no-changeset label, same as test(control): golden regression corpus for ComputeDispatch #790.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c134fd551c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Verify the charge-block predicates in named records

When these scenarios are regenerated after their inputs drift, this check only verifies that the aggregate live battery power exceeds one slew step. An idle-slot record can become a non-idle plan, the stale-plan record can become fresh, or ChargeBlocked can be removed while the battery remains above the rate, and all three still pass; because replay uses the newly recorded inputs, it will pass too, leaving the safety cases this assertion claims to preserve uncovered. Validate each named record's mode, slot/gate, and relevant blocked battery in addition to its anchor.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Exclude non-positive rates from realistic coverage

When a regenerated family accidentally uses zero or negative slew rates, every binding record is counted as production-realistic by this comparison. Those values cannot represent deployed configuration: config.applyDefaults turns zero into 3000 W and validation rejects negative values. Such a corpus can therefore satisfy both 60-record gates without exercising any rate a site actually runs; require a positive lower bound as well as the 3000 W ceiling.

Useful? React with 👍 / 👎.