docs: R-165 merge built and proven at the bake; R-163 + R-175 closed, R-178 filed

07-backup-architecture.md gains §7.5.1 (S-1: the contract changed in the same
session): the ceiling §7.5 describes no longer exists for a box built from
golden >= 0.192.0, the bulkhead's replacement is recorded, and R-175 is FIXED
here rather than left standing — the bound is restated as a function of mp1
and scoped to split-layout boxes, naming all three real shapes.

Capability map: new row as IMPLEMENTED, deliberately NOT proven-live, with
the missing leg named — no box has been reinstalled from the golden, and
"the golden baked" is not "a box built from it works".

R-163 CLOSED: the ceiling it recorded stops existing. R-176(a) answered by
P1; (b) WITHDRAWN, since every node is reinstalled rather than migrated.
R-178 filed for the reinstalls, which were not done this session.

CONTEXT S-13 (the variant chosen on measurement; pruning rejected with its
reason) and S-14 (prove first, then vouch — the golden is published but
deliberately unvouched, because vouching is what makes a fresh install pick
up a layout no box has been proven from).

STATUS: plain-language section; both operator questions now answered, so the
waiting-on-you item is cleared. Two older entries trimmed so the page did
not grow.

STATUS.md

@@ -65,12 +65,32 @@ barrier against a runaway backup filling the space the machine needs to run; put
 first means that when it comes down, the thing watching is already working and already tested.
 *(R-167, R-158)*
 
+**The backup partition is gone from the base image.** A machine built from now on has one storage area
+instead of two, so a backup can use whatever space the machine actually has free rather than a fixed
+slice decided when it was built. The wall does not move; it stops existing.
+
+**What replaced the wall.** It was quietly doing a second job — keeping a runaway backup from eating
+the space the machine needs to keep running. That job is now explicit: if a backup would push the disk
+below a safe reserve, **that one app's backup is refused, its last good copy is left exactly as it
+was, and you are told.** Nothing is ever deleted to make room; every app has only one local copy, so
+"delete the oldest" would always mean destroying some other app's only copy.
+
+**How the shape was chosen — worth one line, because it was not the obvious one.** Three ways of doing
+it were built and rebooted rather than argued about. All three worked. They differed in what they
+quietly broke: one put your backups inside Docker's own storage, where the normal way of fixing a sick
+Docker would wipe them; another exposed all of Docker's internals to the part of the system that
+manages your drives. The third does neither, and costs one extra line of configuration.
+
+**Nothing has changed on any existing machine.** They keep their current layout and go on working
+exactly as before; they get the new shape only when they are reinstalled. The new base image is
+deliberately **not switched on yet** — nothing will pick it up until a machine has been rebuilt from
+it and checked, which is the next step. *(R-165, R-163)*
+
 ## What we're working on
 
 - **Now:** the last app whose data was never saved; today's decisions written down.
-- **Next:** merging the small backup partition into the large one — **the warnings for it are already
-  done and working**, so this step is now only the partition change. It needs one decision from you
-  first (below).
+- **Next:** finishing the partition merge — **the build is done and the decision is made**; what is
+  left is to reinstall the two demo machines from the new base image and check one end to end.
 - **After:** rebuilding how the machine records whether an app is meant to be running.
 
 ## Waiting on you
@@ -82,35 +102,23 @@ first means that when it comes down, the thing watching is already working and a
   settle both. *(R-110, R-115)*
 - **A job, not a decision: the hub password needs changing.** A diagnostic command printed it into a
   session log; nothing suggests anyone else saw it. *(R-132)*
-- **The partition merge: one decision, now measured.** Removing the backup partition also removes a
-  barrier — today a runaway backup is refused on its own and cannot touch the space the machine needs
-  to run; afterwards it can, and a machine out of that space is stopped, not slow. So: do we add a
-  hard stop that refuses a backup before it eats the last of the room, or do we rely on the new
-  warnings? The recommendation is the hard stop, because it keeps exactly what the barrier gave us.
-  **Second question, which only you can answer:** does the tester's box need converting in place, or
-  can it be reinstalled? It does not report to the hub, so nothing here can tell. *(R-165, R-176)*
+- **Nothing — both partition-merge questions are answered.** You chose the storage shape and the hard
+  stop; both are built. The tester's box needs no conversion: it will simply be reinstalled. *(R-165)*
 
 ## Changed since last update
 
-- **2026-08-02** — The false "host offline" warning is fixed, and the cause was not what it looked
-  like. The hub's database was supposed to be in a mode where reading a page cannot block a machine's
-  status update — the code said so, but a one-word syntax difference meant the setting had **never
-  taken effect**, for the hub's whole life. So opening an operator page could make a machine's report
-  fail; two failures in a row crossed the half-hour threshold and sent you an alert about a machine
-  that was up and healthy. It had already done that twice that day. Now genuinely fixed and verified
-  live. **Also found while checking it: the hub's own database is not in any automatic backup** — it
-  holds every machine's emergency password and the escrow records. Filed, not yet fixed.
+- **2026-08-02** — The false "host offline" warning is fixed. The hub's database was supposed to be in
+  a mode where reading a page cannot block a machine's status update; a one-word difference meant that
+  setting had **never taken effect**, for the hub's whole life. Fixed and verified live. **Also found:
+  the hub's own database is in no automatic backup** — it holds every machine's emergency password.
+  Filed, not yet fixed.
 
-- **2026-08-02** — Boot recovery finished: the machine records what the customer asked for, and waits
-  for the system to finish starting before deciding what is missing. Six hard resets, everything back
-  every time. A hole the previous day's change had opened — starting an app whose external drive was
-  missing — was found by reading the code, reproduced on the demo box first, and fixed the same day.
-  **A second instance of the same hole was found and fixed today**, on the path that restarts an app
-  after an interrupted backup.
+- **2026-08-02** — Boot recovery finished; six hard resets, everything back every time. Two instances
+  of the same hole — starting an app whose external drive was missing — were found by reading the code
+  and fixed the same day.
 
-- **2026-08-02** — Thirteen mechanical checks had built up across the four repositories and nothing
-  ran most of them; two were failing quietly, one since 14 July. Both fixed, and the arrangement that
-  replaced them is described above.
+- **2026-08-02** — Thirteen mechanical checks had built up and nothing ran most of them; two were
+  failing quietly. Fixed, and the arrangement that replaced them is described above.
 - **2026-08-02** — Decided: the 20 GB backup partition goes away and shares space with app data. That
   changes the disk layout, so it happens before any machine is installed outside the house. **Measured
   since:** no machine outside the house is registered yet, so this is as cheap now as it will ever be;