Night 2026-10-19: register 161 -> 161 (closed R-921, R-953, R-986; opened R-1168..R-1170; R-1001/R-1011/R-1010/R-1070/R-1167 READY, R-893 READY with the measured design note -> D20, R-1083 gap); morning list in STATUS; 03/05/07/11 updated; R-893 evidence

documentation/architecture/03-host-agent.md

@@ -232,7 +232,11 @@ The controller (in its LXC) reaches the agent (on the host) over the local bridg
   - `POST /rollback` — roll *this* guest back to a named snapshot (post-deploy failure recovery).
   - `POST /backup` — request a backup-now of *this* guest (enqueued; non-destructive).
   - `GET /backup/due` — whether a policy-scheduled backup is due for *this* guest, so the controller can quiesce then call `POST /backup` (the app-consistent path, §8).
-  - `GET /backup/status`, `GET /restore-test/status` — read-only status for the controller's UI.
+  - `GET /backup/status`, `GET /restore-test/status` — read-only status for the controller's UI. **`host_busy`
+    (R-921, agent Unreleased `56aabc7`):** `GET /backup/status` also says whether the host-wide heavy-operation gate is
+    held (`{busy, what}` — another guest's backup, the restore test, an OS step, the stale-lock sweep, a power-off), the
+    state in which `POST /backup` answers 409; absent when the gate is not wired. The controller (≥ 0.335.0) reads it
+    before it stops any app. A read, never a reservation.
   - **Crash-boot fact (R-856, agent v0.149.0):** `GET /host/crash-guard` — the host crash guard's last-boot record
     (`present`, `last_boot_at`, `last_boot_unclean`, `tripped`) read from `/var/lib/felhom-crash-guard/state.json`; a missing
     or garbled file answers 200 `present:false`, an older agent 404 — both read as a normal boot. The controller waits
@@ -399,7 +403,10 @@ per Part 1: **snapshot** (LVM-thin, transient, whole-guest rollback — not a ba
 >   space on …" — so the hub raises `restore_test_failed`; it is never a pass and never dropped.
 > - **Leftovers on a timer.** A failed scratch teardown and the stale-lock sweep (R-673) run every 10
 >   minutes, not only at agent start; the sweep holds the one-heavy-operation gate; after 3 failed
->   teardown tries the operator is told.
+>   teardown tries the operator is told. **A half-removed `vzdump` snapshot (R-1010, agent Unreleased
+>   `56aabc7`):** when the sweep's delete fails ONLY with „Failed to find logical volume …_vzdump" (one disk's
+>   snapshot already gone), it retries once with Proxmox's own `force=1` on the same API call (no sudoers line, no
+>   root command); any other error is returned unchanged, and a failed forced delete is never forced again.
 > - **A thin pool ≥ 90 % requests an immediate report**; the hub judges a thin pool on the worse of data
 >   and metadata, critical at 90 %, one alarm per pool per 6 hours (`08` §6.2).
 >