R-265 CI timeout + golden 0.210.0 baked; R-221/R-259/R-258 closed, R-266 minted, G-3 unblocked

Four defects of one family, all shipped today: something the box already knows, thrown away or drawn
as its opposite. Agent v0.128.0, controller v0.210.0. NO HUB CODE, no hub bump, no ArgoCD sync.

R-265 (this repo). timeout-minutes: 5 on the gates job — every honest run in the observed session
finished in 18-34s, so this is ~9x the slowest and far under whatever reaped run 264 at 834s with no
log. The alarm mail now carries Elapsed (start stamp via $GITHUB_ENV; an absent stamp prints
"unknown (no start stamp)", never a bogus 1.7-billion-second figure) and its "names itself in the run
log" sentence is qualified so it cannot mislead when there is no log.

⚠ THE UNKNOWN IS NOT CLOSED. Whether the if: failure() alarm fires for a REAPED job is still
unverified. The timeout makes the reap unreachable in practice; it does not answer what happens in
one. Demonstrating it means deliberately hanging a run on main, which would leave the branch red for
a parallel session. Said in the workflow comment, the changelog, R-265 and the report — none of them
claiming it is answered.

GOLDEN 0.210.0 baked, published, round-trip verified, NOT VOUCHED. The currency gate went red the
moment the controller was bumped — correct — and is closed by the bake, never --no-verify. No
--no-verify anywhere this session.

⚠ THE AGENT WAS NOT PUBLISHED UNTIL THIS SESSION CHECKED, AND IT MATTERED. R-221's fix is in the
AGENT, and a fresh install takes its agent from the Day-0 manifest. The binary had been hand-deployed
to felhom-pve and never published, so agent_version 0.128.0 was not selectable and a fresh install
would have received 0.127.0 — the golden would have carried the controller fixes and NOT the one the
headline defect needed. Caught by checking each Day-0 value was FETCHABLE rather than assuming.
Published from the live-deployed bytes, sha-verified across the hop first.

Registers. R-221, R-259, R-258, R-265 CLOSED. R-266 MINTED (READY): the failed root statfs still
travels to the hub as a 0-of-0 disk; ranked LOW because it is the quiet direction — it can only miss
a true alarm, never raise a false one — and it is now a two-repo wire change governed by G-1's gate.
Highest ID moved R-265 -> R-266.

CONTEXT S-39 rules the convention this project was missing: "we do not know" is never drawn as
"fine", and the codebase has ONE way of saying it — an explicit ...Known bool companion checked in
the template. ROADMAP G-3 was explicitly blocked on that decision and is unblocked; what remains
there is a survey-and-convert of existing sites, not the gate.

Capability map row 93 CHECKED and it was NOT claiming something untrue — it is about the operator
notification path. But its narrative ("the page you open to ask whether ONE app is backed up")
invites the wrong reading, and the adjacent thing WAS false until v0.210.0, so the row now records
that the two halves disagreed and only the operator half was true.

Six red-proofs across the two code repos, each with the mutation asserted applied. The one that
matters: Part 1 Scenario A FAILED against today's tree, with the intended message.

Part 1's operator-present live validation is OWED and is the session's STOP.

repo_gates --fast: all 8 OK.

STATUS.md

@@ -18,64 +18,64 @@ network, and open apps from a launcher or a shared link. Backups run on their ow
 machine's drive, a second drive, and an encrypted off-site copy.
 
 **The backup promise is proved, and so is getting the data back yourself.** A machine has been
-destroyed on purpose and its files came back byte for byte identical — four times now, including a
-filename with Hungarian accents. On **2026-08-07 the household's own journey passed for the first
-time**: someone with a browser and their recovery code got everything back with **no command line
-inside the machine at any point**. From logging in to seeing what is in the store took **72 seconds**.
-*(R-201 — closed.)*
-
-**And the two rough edges that walk found are gone** — after a rebuild the restore used to stop dead
-twice; both refusals now say what happened, that nothing is lost, and link to the screen that fixes
-it. *(R-252, R-253 — closed 2026-08-08.)*
+destroyed on purpose and its files came back byte for byte identical — four times now. On
+**2026-08-07 the household's own journey passed for the first time**: someone with a browser and
+their recovery code got everything back with **no command line inside the machine at any point**,
+in 72 seconds. The two rough edges that walk found are also gone. *(R-201, R-252, R-253 — closed.)*
 
 ## What's broken
 
-- **Nothing new is broken.** All three secret-in-page faults are fixed; what remains is that the
-  *check* against a fourth covers 4 pages of 27, and the cheap one covering all of them is blind to
-  the shape that actually shipped. *(R-255)*
+- **Nothing new is broken.** The *check* against a fourth secret-in-a-page covers 4 pages of 27, and
+  the cheap one covering all of them is blind to the shape that shipped. *(R-255)*
 - **The machine's own screen keeps telling an already-paired box to pair itself** — 25 minutes after it
   was paired, on a screen that promises it refreshes itself. *(R-214, R-235)*
-- **A rebuilt machine cannot create a new recovery code at all.** *(R-221)*
 - **A backup that covered nothing still calls itself „Sikeres".** The state is honest; the word is not.
   *(R-240)*
-- **A machine waiting for its recovery code can stop backing up off-site without alarming us.** After
-  a *rebuild* we ARE told; the gap is a box reaching that state with no working tier behind it. *(R-243)*
-- **The card offering to reopen set-aside backups promises more than we can deliver** — we keep the old
-  sealed package, but nothing can open it. *(R-202)*
-- **Deleting a customer leaves rows behind** on every test machine ever torn down, while reporting a
-  clean teardown. No secrets involved, but it accumulates with each walk. *(R-244)*
+- **A machine waiting for its recovery code can stop backing up off-site without alarming us** —
+  after a *rebuild* we ARE told; the gap is reaching that state with no working tier. *(R-243)*
+- **The card offering to reopen set-aside backups promises more than we can deliver.** *(R-202)*
+- **Deleting a customer leaves rows behind** while reporting a clean teardown — no secrets, but it
+  accumulates. *(R-244)*
 - **Putting restored files back where they belong is still a manual step.** *(R-213)*
 
-## Fixed today — the thrown-away sentence, and a check so there is no next one
+## Fixed today — four things the machine knew and did not say
 
-We could not tell whether your engineer could get into a machine. The machine says so every few
-minutes; **the hub had nowhere to put the sentence and discarded it on arrival**, so a box with the
-door open, the lock working and **no key issued** was reported as fine. Not a wrong answer — an answer
-to a question nobody was asking. Fixed, and the alert now **names the missing key** instead of saying
-"access degraded". *(R-260, R-247 — closed; hub v0.99.0, controller v0.209.0.)*
+All one family: something the box already knows, thrown away or drawn as its opposite.
 
-**The check was built first and watched failing on 40 facts, before a single one was fixed** — the
-night before, an off-the-shelf tool for a neighbouring shape was rejected for failing exactly that
-test. Of the 40: three now change what we are told, sixteen are genuinely redundant, and **twenty-one
-are recorded as undecided rather than quietly waved through** *(R-264)* — the strongest being
-per-guest network health, which we already lost 1 h 15 m to once.
+- **A rebuilt machine can set up its own recovery again.** The one fact the setup needs was written
+  only the first time, and a rebuild replaced the configuration while leaving the note saying
+  "already done". It is now checked and re-written every minute instead of remembered once, so a
+  hand-edited or restored configuration heals too. **This was the last item blocking a customer from
+  something we promise them.** *(R-221 — agent 0.128.0.)*
+- **A disk we failed to read is no longer drawn as a healthy empty one.** No figures, no bar, and it
+  says so: „A tárhely mérete most nem olvasható ki." *(R-259 — controller 0.210.0.)*
+- **A backup tick now answers about that app.** It went green because *some* backup file existed and
+  *some other* app's database dump had succeeded most recently. Now: that app's own result, and
+  **no mark at all** when we have none. *(R-258 — controller 0.210.0.)*
+- **Our own alarm no longer points at a page that may not exist.** A check run now gives up after
+  five minutes rather than hanging until something else kills it, and the mail says how long it ran.
+  *(R-265.)*
+
+**Not fixed, and said rather than glossed:** that failed disk reading still reaches us as "0 of
+0 GB". It is the quiet direction — it can only miss a true alarm, never raise a false one. *(R-266)*
 
 ## What we're working on
 
 - **Widening the check** so a fourth secret-in-a-page is caught by a machine. *(R-255)* · **Deciding
   the twenty-one** — each gets a reader, or stops being sent. *(R-264)*
-- **Proving the hub really keeps the old sealed key** when a machine re-seals. *(R-198)* · Still open
-  from the overnight sweep, none urgent: *(R-256…R-259, R-261…R-263)*
+- **Proving the hub really keeps the old sealed key** when a machine re-seals. *(R-198)* · Still open,
+  none urgent: *(R-256, R-257, R-261…R-263, R-266)*
 
 ## Waiting on you
 
-- **One approval: move the base image on by one.** You vouched **0.208.0** during the night —
-  thank you, that gap is closed. Today's release went one further, so: Hub → Configuration → Day-0
-  artifacts → Golden **0.209.0** → Save. One field moves, the other two were checked and are right,
-  and it is reversible. *(R-242)*
-- **Fourth time in three days, so worth a minute.** A check now catches the *baking* being forgotten
-  — it caught it again today and refused the push until it was done. **Nothing catches the approval
-  being forgotten.** Two ways to close that are written up, neither built. *(ROADMAP G-8)*
+- **A watching moment, five minutes.** Today's recovery fix is proved by removing one line from a
+  demo machine's config — backed up first, disposable machine, no customer data near it — and
+  watching the setup screen go green on its own. Nothing is destroyed. Say when.
+- **One approval, three values this time.** Hub → Configuration → Day-0 artifacts: Golden
+  **0.210.0**, Agent **0.128.0**, minimum agent **0.127.0** (unchanged) → Save. Each was checked to
+  be downloadable and selectable before being written here. **Agent 0.128.0 is the one that carries
+  today's recovery fix**, so a new machine needs both, not just the image. It supersedes the 0.209.0
+  approval you already gave, and it is reversible. *(R-242)*
 
 ## DooPlex infrastructure — separate from the product
 
@@ -91,3 +91,6 @@ being readable.*
   it writes PASS/FAIL to `/var/log/felhom-store-postboot-check.log`. On PASS, 34 GB comes back. *(R-209a)*
 - **Backup scripts on DooPlex are unversioned host state** *(R-231)*, and the instruction-file
   follow-ups each need a decision rather than an edit *(R-229, R-230)*.
+- **Our build-check alarm has one gap left.** A run that hangs is now cut off after five minutes and
+  the mail says how long it took — but **whether the alarm fires at all when the machinery kills a
+  run outright is still unverified**, and we have not claimed otherwise. *(R-265)*