Save Auto-Calibrate results without asking

[Purple10101]

Summary

Two changes to the Auto-Calibrate window, for ClickUp 123zgec4dua ("Autoconfig Confusing"). A customer ran Auto-Calibrate, saw a successful result under two copies of an orange warning, pressed Persist to config, and was left unsure what they had just done.

1. The preflight restart note is gone. When the preflight found the radio unresponsive and restarted it, the window showed an orange note: "The radio had stopped accepting tuning commands and was restarted ... maximum attenuation ... has been saved to the configuration." On a successful run it appeared twice, because the running view put it in the error box and the success view added it again without clearing that box. It sat right above a Persist button that contradicted it. It described something already fixed, so it read as a current fault. The run still records the restart in status["preflight"]. A run that cannot recover the radio still explains why in its own error message.
2. There is no Persist button any more. When a run ends with tuning to keep, the window calls /calibrate/apply itself. That covers a confirmed result, and the no-track fallback that every Quick Calibrate ends with. It's the same route, the same user.yml write and the same apply queue the button used, so the server side is unchanged. Progress shows on a line under the result, using the apply's own phase labels, and ends in "Saved and applied." A failure is shown in red. A cancelled run has no tuning, so it saves nothing, as before. The setup wizard already saved this way. Its only change is a comment.

Behaviour to be aware of

• The save starts from the browser. If no tab has the window open when a run finishes, nothing is saved, the same as when nobody pressed the button. Once the request is sent, closing the tab does not matter.
• Two tabs watching the same run would both save. The apply queue folds the second into one extra restart pass, so it is safe, just one restart more than needed.
• This does not fix the customer's radio dying after the save. That looks like a cold-start problem in blah2, where tuner B briefly starts at tuner A's gain. It is addressed separately in Start both RSPduo tuners at the less sensitive gain reduction blah2-arm#74.

Verification

• Full suite: 1,018 passed on ed5e9b7. Two new wiring tests cover the missing button and both run endings saving through /calibrate/apply. The test that located form-adoption code by the old button's click handler now uses the new function.
• Live on owl-ded9 in a real browser (headless Chromium, clicking Quick Calibrate then Start as a user would). Only this branch's two commits were applied to the node's existing checkout, which was reverted afterwards:
  • The run went: preflight, then search (3m07s), then a 45 s soak, then "Tuning resolved".
  • The window then POSTed /calibrate/apply by itself, exactly once. It showed "Restarting the SDR service", then the 30 s settle countdown, then "Restarting radar services", then "Saved and applied", 46 s after the run ended.
  • There was no Persist button and no orange note. The unsaved-changes pill stayed hidden, and Close was the only button left.
  • The radar came back after the restart, at -21 / -23 dBFS.
  • Not covered: owl-ded9 has no illuminator, so the run ended on the tuning it started from (20/20/LNA 1). The Capture fields were updated but did not visibly change. A node where calibration moves the gains would show that.

Test plan

• Full test suite
• Quick Calibrate on a live node saves by itself, once, and the radar comes back
• Auto-Calibrate on a node with an illuminator: result saved, and the Capture fields show the new gains without a reload

🤖 Generated with Claude Code