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/07-backup-architecture.md

@@ -728,7 +728,13 @@ definition is written or a named volume replaced — a failed placement, volume
 the live definition back and HOLDS the app stopped (`restore_mixed`, operator-cleared); the household reads that it
 needs our help; the operator gets a `backup_run_failures` line. The hold is persisted before the stop. Placed files
 ALONE (no version change, no volume replaced) still restart after a successful rollback (`TestR379_ScenarioA`): that
-mix, and the undo of everything, is option A — „put back exactly as it was", the next slice on R-893.
+mix, and the undo of everything, is option A — „put back exactly as it was", the next slice on R-893. **`[FACT]`
+2026-10-19 (measured on 9202, controller 0.335.0, `audits/night-2026-10-19/P3/`):** a forced replay failure after the
+volume was replaced left the NEWEST rows (the undo dump) on top of the backup's volume — a table only the backup had
+stayed (37 tables, the live app had 36); the definition did not move (same version); the app was held and a start
+answered 409. The restore page's „the database is back as it was" is false for it. Design note with the two options and
+the pick (A: a copy of the app's live volumes, put back on failure — one copy's disk for the restore's length, a fit
+check before the stop): `audits/night-2026-10-19/P3/design-R-893.md`; the decision is on `STATUS.md`.
 
 **[DESIGN] 2026-08-22 — the failure ladder of a database restore: replay → rollback → hold.**
 Recorded here rather than only in a closed register row, because a decision that survives only inside
@@ -826,8 +832,12 @@ parts above, not a measured press).
 demo-hp: the off-site tier stopped every app for ~1 min and the agent then refused it (BUSY: the night OS step held the
 agent's host-wide lock). Before stopping anything the controller now asks the agent which tiers have a job in flight
 (`GET /backup/status`); another tier's job running or snapshotted → no stop, the tier stays due. A refusal after the
-stop still resumes the apps at once (pinned by test). **Not covered:** the host-wide busy lock (OS step, restore test,
-fstrim) — the agent serves it on no endpoint, so the measured case needs an agent change too (R-921, LEFT).
+stop still resumes the apps at once (pinned by test). **The host-wide busy lock (2026-10-19, operator answer „add one
+field"):** the agent serves it as `host_busy` on `GET /backup/status` (agent Unreleased `56aabc7`); controller 0.335.0
+(the floor) reads it before any stop — held → no app stopped, each due tier recorded as contention (retry in 15 min,
+one „BLOCKED" alarm after 3 h), exactly the verdict a 409 gets. An agent without the field keeps the old order (stop,
+ask, resume at once). The check is a read, not a reservation: a gate taken between the read and the start costs one
+short stop, resumed at once. The measured case is closed on a box once it runs the next agent release.
 **Measured 2026-10-05 on demo-hp (9 apps, controller v0.295.0):** „Mentés most" stopped the apps at 09:19:08Z, the
 local tier ran 09:19:29–09:24:09, the PBS tier was busy (the controller logged a retry in 15 min; no second stop was seen in the next 55 min), the last app was back at 09:24:55Z — the
 longest stop **5 min 47 s**, for the local tier alone. The button text and its confirm (v0.296.0) give both