hub v0.105.0: the third name, a machine told to be quiet, and a guard for the hub's own words

Hub only. No controller change, no agent change, no wire change — nothing to bake.
demo-hp untouched: the operator is re-deploying it this evening.

R-323 — the five-word phrase is „Tulajdonosi jelmondat". It was „Visszaállító
jelszó": one word from the name retired last week, and false besides — it restores
nothing, it proves the account owns the box being bound. Five sites, all in the hub;
felhom-controller and felhom-agent carry the name nowhere, so no halt and no bake.
Both suggested names were rejected with reasons: „Fiókjelszó" would collide with the
dashboard login (a DIFFERENT real secret), and „Összekötési jelszó" would leave the
two factors on this page separated only by kód-versus-jelszó — the exact shape being
removed, since the other factor is the „Párosító kód". The chosen name differs on
both axes, stem and noun. Naming only; the acceptance pin drives the real handler.

R-324 — the hub's customer copy is under a guard for the first time. Retired names
banned across all 95 hub files; retrieval stems registered in four declared customer
surfaces. The selftest found a defect in its own instrument on the first run. One
shared vocabulary in scripts/, drift-checked into the controller gate rather than
copied (R-325 removes the scaffold).

R-321 — a machine we told to be quiet is no longer reported as dead, and it was two
doors, not one: because the state is RECORDED rather than deleted, the morning
deadline check can skip it too. A deleted state returns "", which is not "down" —
R-195's shape returning through a second door. The clock runs from the report the hub
can see, so re-enabling starts it there and emits no recovery for an outage that never
happened. Three red-proofs; the one that matters showed a genuinely dead machine
sitting at "disabled" when the suppression was made unconditional.

R-326 — "which claims are unproven" is answerable by a command now. The nine I have
been repeating was the count of claims the 9 August pass DOWNGRADED, not the count of
unproven ones. The real figures: 55 claims, 23 walked, 32 not — and only 6 of those 32
cite evidence. Its first run found a stale claim (R-327).

CLAUDE.md

@@ -125,6 +125,13 @@ something, not only sessions that touch `documentation/` — which is why it is
   the operator in plain language, and deliberately **not** `CONTEXT.md`.
 - **The capability map** (`documentation/architecture/00-capability-map.md`), if a capability's
   status changed — with its new evidence citation.
+- **`python3 scripts/unproven.py --summary`** — one line per status, and the not-walked total. Run it
+  at the end of any session that shipped, broke or proved something, and **say in the report if a
+  number moved**. It exists because "which claims are unproven?" was answerable only by a person
+  reading a page: a session asked for "the nine grey claims" could not determine which nine and
+  rightly refused to guess (R-326). *Nine was real and answered a different question — it is the
+  count of claims the 2026-08-09 pass DOWNGRADED. Not-walked is 32 of 55.* A status that moves
+  without anyone noticing is how the picture stops being true.
 - **Confirm your own last push's CI run went green, by run ID.** CI emails on failure, which is a
   PUSH signal; this is the PULL check that catches a lost, filtered or unread mail. Quote the run id
   and its conclusion, e.g.