hub v0.104.0: the guest network gets a reader (R-319), and the hub half of the naming (R-295)

Four paper debts and one fact given a reader. Hub-only — nothing to bake.

A4 — the entry about "the tester's machine" named a risk correctly and labelled it
in a way that invited deleting it. Established from the hub's own store: `peti-felhom`
is a REAL machine (482 reports, 2026-02-27 → 2026-07-15, a named person's own box) and
the 3.6 GB with no key and no backup is real. `david` → `tester-1` is a DIFFERENT record
with no host, no escrow and no report, ever — deleted 07:55:49 and re-created 07:56:47
this morning. The prompt's premise conflated the two; the register now says which is which.

A1 — R-312/R-313/R-303 recorded as DECIDED with their re-open triggers, and moved out
of STATUS's "Waiting on you", which is now empty.

A3 — day0-install §C.1 said pushing the installer publishes it. It has not since
R-110. Corrected, with the two manifest pins named and an outside-verification command;
the one copy that repeated it (a dated audit, true when written) carries a superseded note.

A5 — standing rule 5: evidence comes off the machine at the end of the phase that
produced it, before any revert. Earned twice in three days on the same box at the same
point (R-320). Four homes, plus what to do when it is already gone.

R-295 hub half — „Beállító kód" everywhere; „Visszaállító kód" retired. New `reenroll`
mail kind so the mail names the page a REBUILT box actually shows („A szerver
beállítása"), not the „Elfelejtett jelszó" page it has no login screen to reach.
Naming only; the acceptance pin proves the secret is untouched.

R-319 — the hub models `guest_net` after 23 days of receiving and discarding it. The
signal is `heals_last_hour`, not `state`: a guest the watchdog keeps repairing reads
healthy between repairs. `heal_succeeded` decoded too (R-260's lesson). Unknown is never
drawn as healthy — three absences, three sentences. No alarm, deliberately.
Three red-proofs, mutations asserted applied. Wire-gate checked tags 182 → 190.

B1 — the operator's 2026-08-12 dispositions were NOT in the register; they are now.
Third allowlist kind for the five ruled "no reader wanted"; `reporting_disabled`
reclassified redundant. 8 read · 5 deliberately unread · 1 redundant · 6 still owed.

Also filed: R-321 (a deliberately-silent box still alarms stale/down — the checker is
age-only, and decoding the flag would not have fixed it), R-322 (the claim guard has
never scanned the hub; a hand scan returns zero, so it is a scope gap, not a defect).

documentation/PROMPT-TEMPLATE.md

@@ -476,7 +476,14 @@ Report MUST include:
 6. **Deployed versions** + `docker ps` / agent-service / hub-pod verification output.
 7. **NOT yet live-validated — awaiting supervised [Bx]:** explicit list (the real
    put-data → operate → integrity flow).
-8. **Teardown evidence — all three §13 layers**, if the run provisioned anything: the machine deleted,
+8. **Evidence copied off BEFORE each revert** — for every phase that ran on a machine, the logs were
+   pulled to the evidence directory **at the end of that phase**, before any revert, snapshot restore
+   or teardown, **including the intermediate ones**. *The intermediate revert is the one that gets
+   forgotten: two sessions lost a phase's logs to a mid-run revert to `virgin` on 2026-08-12 and
+   2026-08-13 — same machine, same point, three days apart (R-320).* **If a phase's evidence is
+   already gone, the report says so plainly and the finding is REPRODUCED independently** — that is the
+   expectation, not an improvisation. A quotation read live and no longer re-readable is named as such.
+9. **Teardown evidence — all three §13 layers**, if the run provisioned anything: the machine deleted,
    `pvesm status` before/after with the space returned, and the **hub-side record's disposition named**
    (deleted / retained-with-reason / gate-blocked-with-the-command). A run that provisioned nothing says
    so. "Teardown clean" without layer 3 is not a report — it is the `sess-c` failure.