clear_hold (D64 = B) + the box command through the running controller (R-1343), R-1340, R-1341 — tests red first; commit only

- clear_hold: a fifth verb in the closed operator-action list; lifts a hold of any reason in the RUNNING
  controller (memory + settings.json together), forgets the update's held flag, drops a waiting put-back
  from the app-stop marker (copy kept). Refused on a bad name or no hold. No new event type.
- --clear-restore-hold asks the running controller over <data dir>/ctl/hold.sock (unix, 0600, peer uid
  checked, no TCP); edits settings.json only when no controller answers, and says so (in-guest restart).
- R-1340: the operator's HELD STOPPED mail is built from the hold record (restore kind, mixed cause,
  failed put-back step, database replay or not, kept copy) — never the option-C database story by default.
- R-1341: the OOM WARN line once per new kill (container, start time, kill count); event unchanged.

controller/README.md

@@ -1017,7 +1017,8 @@ Each app can define rich metadata in `.felhom.yml`:
     the hold is persisted in `Settings.RestoreHolds`, every start path refuses it (customer button,
     app-stop `Recover()`, boot sweep, via `driveStartGate` **above** its driveless early return), the
     app-stop marker is ended so nothing auto-restarts it, and the row goes red. Cleared with
-    `--clear-restore-hold <app>`, **which requires a controller restart**. `--single-transaction` on
+    `--clear-restore-hold <app>` (since 2026-10-29, R-1343: through the running controller, no restart — see
+    „Operator actions") or the hub's „Clear hold" (`clear_hold`). `--single-transaction` on
     the Postgres import is a belt only; MariaDB DDL is not transactional, which is why the rollback
     is the fix.
   - **Off-site restore of one app: a failed restore puts the app back EXACTLY as it was and starts it (v0.336.0,
@@ -3655,6 +3656,19 @@ Anything else is answered `refused` and calls nothing. Each id runs once per pro
 (`operator_action_results: [{id, outcome, message}]`, outcome `done` / `refused` / `failed`). No action deletes data,
 starts a countdown or shortens one (`TestOpActions_ClosedList`). The box's log records every action it receives.
 
+- **`clear_hold` (2026-10-29, operator ruling D64 = B; arg = the app's stack name, letters/digits/`-`/`_`, ≤64):** lifts
+  the app's hold of ANY reason, in the RUNNING controller (`backup.AppStopGuard.ClearHoldByOperator`, the door
+  `clearHoldNow` in `cmd/controller/holdclear.go`): memory and `settings.json` together, so no later save writes it back
+  (R-1343). It starts nothing — the household's Start (or a restore) does. A waiting put-back (`putback_pending`) is
+  dropped from the app-stop marker too; its copy stays on disk. The update's in-memory „held" flag
+  (`stacks.Manager.ForgetUpdateHeld`) goes with it; the hold reporter's next tick (≤1 min) sends `app_hold_cleared`.
+  Refused, nothing changed: a bad name, or an app with no hold. No new event type: the hub records the result.
+- **The box command `--clear-restore-hold <app>`** (`pct exec <vmid> -- docker exec felhom-controller felhom-controller
+  --clear-restore-hold <app>`) asks the running controller over a unix socket, `<data dir>/ctl/hold.sock` (0600 in a
+  0700 dir, peer uid checked, nothing on TCP — not reachable through traefik, the LAN or an app), and says no restart is
+  needed. Only when no controller answers does it edit `settings.json` itself, and it says so, naming the in-guest
+  restart. `--restore-holds` lists the holds (read-only).
+
 #### Report Push (`internal/report/`)
 
 Periodic JSON push (default every 15 min) to the central felhom-hub service: