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, and serving them 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 by the caller.

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.

Also: golden 0.214.0 baked, published and round-trip verified; the countdown on
demo-felhom cancelled on the operator's ruling (R-307); the spike that halted
Part 3 recorded as R-312; the set-aside store found unrecoverable as R-313.
Six hub tests through the real endpoint; four red-proofs asserted applied.

CONTEXT.md

@@ -15,6 +15,29 @@
 > would make one of the two audiences stop reading. `STATUS.md` is also a **view of `OPEN-ITEMS.md`**
 > and holds nothing of its own; this file does hold its own content, namely the standing rulings below.
 
+## Material retained is not history recoverable — ask the three questions separately (2026-08-12)
+
+**"We keep the old key" and "the customer can get their old backups back" are three questions, and
+collapsing them is how a false belief survived a week.** Ask them one at a time, and answer each with
+its own evidence:
+
+**(a) Is the material retained?** **(b) Does it, once unsealed, still open the old store?**
+**(c) Does the customer have a ROUTE to (b) through the product?**
+
+Measured 2026-08-12, and the answers were **yes, yes, no** — a shape nobody had predicted. Our records
+predicted (a) yes and (b) no ("a box we fill and cannot open"); the drill found (b) works and **(c) was
+the missing one.** `ListSupersededEscrow` had held the right bytes since v0.93.0 with **zero production
+callers**, so the capability existed and was unreachable. The same afternoon's follow-up shipped a
+partial (c) — the product now RECOGNISES a correct code for an earlier package — and established that
+the rest of (c) is new surface, not wiring, because every restore entry point resolves its repository
+from settings and its password from one file (R-312).
+
+**The generalisation, which is the part worth keeping:** a stored artifact proves storage, never
+usability. Between "the bytes are kept" and "the customer is helped" sit an unseal, a consumer and a
+route, and each has been separately absent in this project. **Before claiming a capability, name which
+of the three you have evidence for** — and if a comment or a card asserts the third, find the code path
+that performs it or move the claim.
+
 ## Two rules earned twice each (2026-08-12)
 
 **A fact must be recorded at the moment it is a fact, not inferred later from something adjacent.**