R-361 docs: the [FACT], the negative that cancelled Part 2, R-383/R-384, golden 0.221.1

07-backup-architecture.md gains a dated [FACT] on R-361 - a comment asserting an
invariant the code did not have, for four months - and a [DESIGN] on the db_dumps
decision INCLUDING the trap it created: a stable list lets the already-current
early return fire, so per-capture housekeeping must sit above it.

00-capability-map.md records the NEGATIVE from Part 3 so it is not re-derived: a
held app does NOT raise the dead-app alarm. It aggregates to unhealthy, which
IsDownState excludes. Measured on the shipped build with the scans demonstrably
running over it. No suppression was built and no row opened.

R-383: the double-failure message names an undo copy that is not there - R-361's
own class, one surface over, observed on both 0.220.2 and 0.221.1.
R-384: an app whose database has died reads unhealthy and raises no alarm.

R-361 closed and compressed. OPEN-ITEMS 325236 -> 327266 bytes.

Golden 0.221.1 baked, published and round-trip verified. The golden-currency gate
blocked this push and that block is not circular, so it was satisfied rather than
bypassed - no --no-verify anywhere in this session.

STATUS.md

@@ -12,11 +12,11 @@ NOT yet delivered: two steps below are yours.**
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **Vouch the golden carrying controller 0.220.2** — Hub → Configuration → Day-0 artifacts.
+1. **Vouch the golden carrying controller 0.221.1** — Hub → Configuration → Day-0 artifacts.
    **It is already baked, published and round-trip verified**
-   (`documentation/tests/golden-0.220.2-2026-08-22/`); only the vouch is left, and only you can do it.
-   **It is a THREE-field save:** `golden_version` → **0.220.2**, `agent_version` → **0.130.0**,
-   `min_agent` → **0.129.0**. **Then** raise the floor to **0.220.2**, last, in its own save.
+   (`documentation/tests/golden-0.221.1-2026-08-23/`); only the vouch is left, and only you can do it.
+   **It is a THREE-field save:** `golden_version` → **0.221.1**, `agent_version` → **0.130.0**,
+   `min_agent` → **0.129.0**. **Then** raise the floor to **0.221.1**, last, in its own save.
    **If you do nothing:** the fleet stays on 0.219.0, so a failed database restore still leaves an app
    broken with an unusable copy — the thing today's release fixes reaches nobody. New machines still
    receive 0.219.0. The build system stays red about it and will mail you on every push.
@@ -50,6 +50,14 @@ off. **`peti-felhom` is a real machine we have not heard from since 15 July** an
 
 ## Shipped
 
+- **Taking the safety copy no longer destroys the app's own backup** (R-361, controller 0.221.1,
+  proven on `demo-hp`). Before every restore the machine saves a copy of your live database. To do
+  that it called the ordinary backup routine — **which always writes to the app's normal backup
+  filename first** — so the app's real backup was overwritten and then renamed away. Until the next
+  nightly run the app had **no database backup of its own**, and a local recovery in that window would
+  have told you the app never had a database. A comment in the code said this could not happen; it
+  could, and had been happening for four months. Proven fixed the only way it can be: the app's own
+  backup file is now **byte-identical before and after a restore**, on both database types.
 - **A failed database restore now puts your data back by itself** (R-379/R-380, controller 0.220.2,
   proven on `demo-hp`). Until today, if a restore of an app's database went wrong, the machine had
   already taken a copy of your live database — a good copy — and **nothing in the product could put it