20260906 - Offer the wizard's quick calibration from the Configuration page

[Purple10101]

What

The quick calibration run (current tower, descend then soak for overload, no track wait) was only reachable from the setup wizard. An owner who wanted it afterwards had to re-run setup or sit through a ~15 minute full search.

This adds a Quick Calibrate button beside Auto-Calibrate in the Capture section, running exactly the wizard's run.

The run shape is now defined once

Both callers post RetinaCalibrate.QUICK_RUN ({scope: 'current_tower', skip_confirmation: true}) instead of building their own body. Two entry points free to spell out their own run shape is the drift static/calibrate.js exists to prevent, and a test fails if either reconstructs one.

Three fixes the modal needed to describe that run honestly

A quick run terminates in state: "failed" by design, because there is no confirmed result when none was asked for. Rendered by the pre-existing terminal branch alone, it would have:

• reported a successful run as "No calibration found" in red. Now "Tuning resolved", with the engine's explanation in body text.
• offered "Closest attempt ... try these as a starting point", which is advice for a run that fell short. Suppressed, since the box below already names the tuning the radar is on.
• labelled the run "Standard", promising a track wait that was never coming. The Mode row now reads "Standard (quick check)" whenever skip_confirmation is set, which matters because the modal reattaches to any run, including one the wizard started.

The soak summary ("Held cleanly for 45s with no sign of overload") moved into the shared driver so both places report it in the same words, and opening either button while a run is going now attaches to it rather than offering a Start that would only earn a 409.

Deliberate differences from the wizard

Persisting stays an explicit "Persist to config" click here. The wizard auto-persists, but silently writing user.yml under a page the owner may be mid-edit on is worse than one more click. The quick prompt also skips the mode question: a run that never confirms anything cannot answer "how should it decide it's calibrated".

Risk

The engine, the route and the run shape are untouched. Both Python files in the diff are comment-only; every behaviour change is JavaScript in a modal that already existed.

Two places that are not purely additive:

• The wizard's start body now depends on an export. If QUICK_RUN ever fails to resolve, start(undefined) posts an empty body and the route defaults to a full three-tower run: the wizard step would quietly take ~15 minutes instead of 4 rather than erroring. Guarded by the static export test.
• The Auto-Calibrate button now waits on a status fetch before the modal opens, where it previously opened instantly. That is what lets it attach to a run in progress.

Testing

• Full suite green: 885 passed.
• New TestQuickCalibrateEntryPoint covers the shared run shape, that neither caller rebuilds its own start body, and that the terminal branch still distinguishes a run that never looked for a track from one that looked and found nothing.
• Deployed to owl and verified serving: /config 200 with the new markup, calibrate.js serving QUICK_RUN, no errors in the journal after restart.
• Not yet exercised in a browser. The Configuration-page modal has been unverified in a browser since the driver extraction, and this change touches its terminal render, so a click-through is worth doing before merge.

🤖 Generated with Claude Code