DRILL: the retained key works, and the customer cannot reach it

Three verdicts, kept separate because collapsing them is how this assumption
survived a week.

(a) The material IS retained. host_escrow_superseded id 11 is the first retained
row in fleet history to carry identity_blob (572 B), byte-identical to the
pre-supersession row (sha256 a10032341c8584ed...).

(b) The retained material DOES open the old store. Unsealed with the old recovery
code it yielded a password byte-identical to the pre-change one, and restored
three planted files byte-identical from a store the box itself could no longer
open - including a Hungarian accented filename verified as raw bytes. Negative
control ran first and failed closed.

(c) The customer has NO route, and is misinformed. ListSupersededEscrow has zero
production callers; the recovery path selects FROM host_escrow. Asked with the
code that had just worked by hand, the product answered "the recovery code did
not open the sealed bundle". A valid code for retained history is reported as a
bad code - the R-224 class again. R-304, rank 1.

Both installer faults were watched happening first, so installer-v1.27.0 is now
published (tag + both webpage.yaml refs). Pre-fix: the box came up on controller
0.98.3 against a vouched 0.213.0, below the floor and below the version carrying
the recovery screen; and our own uninstall left dnsmasq on 0.0.0.0:53 so our own
next install refused. R-297 and R-300 CLOSED.

Also filed R-305 (the dnsmasq fix fires once per machine - the leftover returns
on the second reinstall, proven), R-306 (--preflight-only writes state it says it
does not), R-307 (a live abandon countdown on demo-felhom, firing 2026-08-24 -
operator decision), R-308 (stored controller password stale), R-309 (the day-0
runbook's publication claim has been false since R-110), R-310 (two edges).

Ceiling R-303 -> R-310. Capability map moved: the retention claim is now marked
operator-only. Phase A logs did not survive the intermediate revert; recorded.

STATUS.md

@@ -1,6 +1,6 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-12 (evening).**
+**Updated 2026-08-12 (late evening — retained-key drill).**
 
 > **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
 > part of it in plain words, and **nothing may exist only here**. **Items, not paragraphs. One screen.**
@@ -8,12 +8,15 @@
 
 ## Waiting on you
 
-- **Vouch golden 0.213.0** — three fields together: golden **0.213.0**, agent **0.128.0**, min agent
-  **0.127.0**. Both are already verified downloadable and selectable.
-- **Raise the floor to 0.213.0** afterwards if you want the fix on the existing machines. The floor is
-  **0.212.0** (raised 2026-08-12; both demo boxes confirmed on it), and boxes update to the *floor*,
-  never to the newest — so until you raise it, v0.213.0 reaches newly installed machines only. One
-  field, reversible; the R-216 hold does not apply, since min agent 0.127.0 is below the vouched 0.128.0.
+*(The golden-vouch and floor-raise asks that stood here are **done** — the hub reads golden **0.213.0**,
+floor **0.213.0**, agent **0.128.0**. Checked live, not assumed.)*
+
+- **R-307 — a countdown is already running on `demo-felhom`**, started 10 Aug, **firing 24 August**,
+  after which that set-aside off-site copy is deleted for good. Today's drill did not start it and
+  deliberately did not cancel it. Cancel it (copy kept, costs storage) or let it run (copy deleted).
+  **Doing nothing chooses deletion.**
+- **R-304 — decide what we promise about old backups.** The retention works, but only an operator can
+  use it; the customer is told their correct code is wrong. Either build the door, or stop promising.
 - **R-303 — one coherence decision**, ranked low: a box can still raise the "we cannot open your new
   backups" card while counting down to deleting the old ones. The two no longer contradict each other,
   but the state is odd and the wrong fix would hide a real second fault.
@@ -36,6 +39,9 @@ Both demo machines are home, healthy and reporting on the approved pair. Off-sit
   fifth deliberately left, because it is true where it renders.
 - **One name per secret, box side** (R-295): the dashboard code is „Beállító kód" everywhere;
   „Visszaállító kód" is retired. It collided with the escrow „Helyreállítási kód" and cost a real code.
+- **Both installer fixes are now PUBLISHED** as `installer-v1.27.0` (R-297 + R-300). Each fault was
+  watched happening first, on a machine reset to factory state: the old installer really did build a
+  machine on a base image from July, and our own uninstall really did block our own next install.
 
 ## Broken, or knowingly incomplete
 
@@ -44,18 +50,19 @@ Both demo machines are home, healthy and reporting on the approved pair. Off-sit
   everything on it is lost.** First act of the visit: copy the ~3.6 GB off before anything is
   reinstalled — it is currently the only copy in existence. Whether it stays parked is your call and is
   deliberately left open.
-- **Two installer fixes are written but NOT published** — pushing publishes nothing, and no tag is cut:
-  - **R-297** — an install could silently reuse an old base image lying on the machine, including one
-    too old to run the recovery screen.
-  - **R-300** — our own uninstall left `dnsmasq` holding `:53`, so our own next install refused and
-    blamed the household's network.
-  Both are unpublished for the same reason: **neither fault has been watched happening.** One session on
-  `drill-r50` covers both, and that is the right order.
+- **Kept backups can be opened — but not by the customer** (R-304). We now know for certain the old key
+  is kept and **does** open the old backups: three planted files came back byte-for-byte from a store the
+  machine itself could no longer read. But nothing in the product reads a kept key, so it takes an
+  operator with a shell. Worse, a customer who types their **correct** old code is told it *"did not open
+  the sealed bundle"*. The keeping is real; the promise that they can use it is not.
+- **The dnsmasq fix helps a machine once** (R-305). On a machine that never had Felhom it works. On the
+  second reinstall the leftover comes back, because the package is never removed — so the machine looks,
+  to our own installer, as if the household had installed it. Watched happening the same afternoon.
 - **The hub half of the naming is undone** (R-295 PARTIAL): the emails still use the retired name and
   send people to a page a rebuilt machine does not show.
 - **The storage page has its own separate reason for showing an empty list** (R-298), untouched.
 
 ## Working on next
 
-The `drill-r50` session that unblocks both installer fixes; then the hub naming; then the
-2026-08-09 batch (R-279 … R-292) which is still untriaged against everything since.
+Your two decisions above (R-307's deadline is the hard one); then R-304's shape; then the hub naming;
+then the 2026-08-09 batch (R-279 … R-292), still untriaged against everything since.