Let a model sweep reset only the runtimes it actually captured

[atomantic]

Summary

#4796 landed the mechanism this issue asked for while this branch was in flight. It gave the model sweep the reset and the per-backend capture/restore — but it also made the sweep refuse outright when any sweepable runtime's launch line cannot be captured. captureLlamaServerConfig returns null whenever llama-server is stopped or was started outside PortOS, so one externally-started daemon now cancels every Ollama and LM Studio model queued alongside it, where before the sweep simply measured them. This PR rebases onto that work and closes the gap.

• Gate the reset on having captured that runtime's launch line, not on isTuningSweepable alone. A reset renders the cleared launch line, which wipes knobs the user set on the LLMs page — only a caller holding what was running there may do that, and an uncapturable runtime left nothing to put back.
• A model sweep no longer refuses. It measures an uncapturable runtime under whatever is running, exactly as it did before the reset existed, and keeps the rest of the queue.
• A tuning sweep still refuses. Varying the launch line is its entire job, so an uncapturable runtime leaves it nothing to do. The asymmetry is deliberate and now stated in the code.
• Drops the dead run.launchState compatibility alias and the unreachable nothing to restore branch in restoreUnderClaim — only captured backends reach the restore map.

Server-side only: server/services/localModelAssessmentSweep.js and its suite.

Test plan

• cd server && npx vitest run services/localModelAssessmentSweep.test.js — 50 pass, including six new cases for the model-sweep dimension A model sweep merges each llama model's tuning onto the previous one's launch line #4774 named: two llama targets each get the complete tuning its record names; one capture per runtime covers the whole queue; a mixed llama+Ollama sweep resets only llama; an uncapturable runtime measures the rest of the queue instead of refusing; it is never reset and reports no restoreError; a two-runtime restore where one daemon throws still brings the other back and names the failing one.
• What a reset then does — clear every sweepable knob the new tuning does not name — stays asserted in server/services/llamaServerManager.test.js ("clears the knobs a reset tuning does not name, so variants cannot accumulate").
• cd server && npx vitest run — full suite green (1564 files, 32773 tests).

Closes #4774