hub v0.103.0 — a host can read the packages we kept for it (R-311)

ListSupersededEscrow had zero production callers for nineteen days. It is the only
reader of a retained identity_blob, so the retention shipped in v0.93.0 was
material the product could not reach - proven on the fixture 2026-08-12, where a
code that opens a retained package was answered as a code that opened nothing.

New GET /api/v1/hosts/<id>/escrow/retained: self-scoped exactly as the current-row
GET, same recovery-mode gate, same audit event written BEFORE the bytes leave,
capped at 16.

Rows with a NULL identity_blob are WITHHELD and returned as unopenable_count.
They retain the PBS key, not the repository password, so they can never open what
the caller is asking about; serving them would have the agent try packages that
cannot succeed and would let the screen claim an earlier package is openable on
exactly the boxes the original defect hurt. The count is returned because their
existence is load-bearing and underivable.

The trade, stated rather than waved through: the hub still cannot read any of it -
sealed bytes in, sealed bytes out, no decrypt path, no recovery code ever held.
What widens is volume, bounded by self-scope, the recovery-mode gate and the cap.

The response is a NAMED TYPE, not a map, so the wire-contract gate can resolve it;
the wire is declared as a fourth ROOT and the gate now checks 182 tags rather than
174. A positive control shows that check is name-presence, not decodability -
filed as R-315 rather than reported as coverage.

Six tests through the real endpoint; four red-proofs asserted applied.

STATUS.md

@@ -1,6 +1,6 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-12 (late evening — retained-key drill).**
+**Updated 2026-08-12 (night — the door, part one).**
 
 > **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.**
@@ -11,12 +11,13 @@
 *(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-312 — one decision, and it is the interesting one.** The customer is now told the truth about an
+  older code, but there is still no button: restoring from a set-aside copy means either threading an
+  alternative location through the restore code, or adopting that copy as the machine's current one.
+  The second is a different product decision. **Nothing is broken while this waits.**
+- **R-313 — the copy you told me to keep cannot be opened by anyone.** `demo-felhom`'s set-aside store
+  holds 36 snapshots and one key, and that key was destroyed by the bug we fixed on 4 August. Keeping
+  it is still the right call; it should be a decision, not an accumulation.
 - **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.
@@ -39,6 +40,12 @@ 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.
+- **A correct recovery code is no longer called wrong** (R-311, three components). If a customer types
+  the code for an older set of backups, the machine now checks the packages we kept, recognises it, and
+  says so: *your code is correct, it belongs to an earlier package, we kept it, your current backups are
+  fine, write to us*. It deliberately promises no restore, because there is no button yet.
+- **The countdown on `demo-felhom` is cancelled** on your ruling (R-307). Nothing was deleted; the
+  24 August deadline is gone. See R-313 for what that copy turns out to be.
 - **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.
@@ -50,11 +57,10 @@ 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.
-- **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.
+- **Kept backups can be opened — but still only by us** (R-304 partly closed, R-312 open). The machine
+  now recognises an older code and says so plainly instead of hedging. What it still cannot do is hand
+  the customer their old files: that needs the restore code to accept a second location, which is real
+  work rather than wiring. Today the honest answer is "your code is right, write to us" — and we can.
 - **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.
@@ -64,5 +70,6 @@ Both demo machines are home, healthy and reporting on the approved pair. Off-sit
 
 ## Working on next
 
-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.
+R-312's shape (the button, or deliberately no button); then R-305, because the tester's second
+reinstall still hits the dnsmasq wall; then the hub naming; then the 2026-08-09 batch
+(R-279 … R-292), still untriaged against everything since.