Control API UX: no pending state, full-pipeline latency for light keys, stale first status, one-shot setup prompt

[VijitSingh97]

Control-API UX findings from a live walkthrough (v1.14.0, all verified against a real rig):

1. A single restart-free key (watchdog_interval_min) via POST /apply took ~62s end-to-end, because the control path re-runs the entire apply() pipeline (rewrites every systemd unit) for any change. Fine as a correctness baseline; worth a fast path for keys that only touch the config file or one unit.
2. During that whole window, GET /status?change_id=<real> returns the same {"error": "no recorded outcome for that change_id"} a WRONG id gets — the poller cannot distinguish "in progress" from "never existed". A pending state (the id is known the moment the request is accepted) closes it.
3. The first no-arg GET /status after enabling control surfaced an 11-day-old record from a prior run ("upgrade to v99.99.99 failed; rolled back…") — documented most-recent-ever behavior, but disorienting with no timestamp-based staleness cue in the response consumer's view. Include the age prominently, or scope no-arg status to the current boot.
4. First-run prompt UX: a bad pool URL exits the whole script (nothing persisted, so harmless) instead of re-prompting — a "start over" where a "try again" costs three lines.