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.

CONTEXT.md

@@ -17,6 +17,45 @@
 
 ## Standing rulings
 
+**S-39 — "WE DO NOT KNOW" IS NEVER DRAWN AS "FINE", AND THE CODEBASE HAS ONE WAY OF SAYING IT
+(2026-08-08, R-259 / R-258; controller v0.210.0).**
+
+Two things collapse into this rule, and they looked unrelated until they were fixed on the same day:
+
+- **A measurement that FAILED.** `readDiskUsage` logged a `statfs` error at DEBUG and returned,
+  leaving the caller's floats at zero — and `usageColor(0)` is `"nominal"`. A disk nobody could read
+  was drawn as a healthy empty one.
+- **A fact about ANOTHER SUBJECT.** The per-app backup tick was set from the box's most recent DB
+  dump run, whichever app it belonged to. An answer about app Y was displayed as an answer about
+  app X.
+
+Both are the same error: **an absence of knowledge presented as knowledge, in the reassuring
+direction.** Neither was a wrong number; both were a confident picture over nothing.
+
+**THE CONVENTION, ruled here so it can eventually be gated.** A figure that can be unknown carries an
+explicit **`…Known bool` companion** beside it, and the template checks the companion **before
+rendering anything** — no number, no percentage, no bar. This is the shape `Offbox.StatsKnown`
+already used (`backups_remote.html`), and its comment states the principle: *"a 0%-wide bar over an
+unread store is a picture of emptiness, and a picture is a claim."*
+
+Pointers and separate error fields are both legitimate Go and both still exist in this codebase. The
+ruling is not that they are wrong; it is that **new** three-state figures use the companion, because
+`ROADMAP.md` G-3 (a gate for this class) is a name-based check and **a codebase with three dialects
+cannot be gated**. G-3 was explicitly blocked on this decision and is now unblocked; the remaining
+work there is a survey-and-convert of existing sites, not the gate itself.
+
+**And the verdict half of the same rule:** where a status has no honest value, render **nothing** —
+`backups_apps.html` shows a check for `ok`, a cross for `error`, and no icon for any third value.
+That empty slot is where "we have no result" belongs. Deriving green from the mere **presence** of an
+artifact is the *presence is not success* rule turned into a UI badge, and this project's own
+capability-map and backup rules already forbid it in prose.
+
+**A test that constructs the receiving struct by hand cannot see either defect** — the dashboard test
+therefore EXTRACTS the meter block from the shipped template rather than copying it, because a copied
+block drifts and a drifted copy passes while the page it claims to cover has changed. That is the
+fixture-is-not-the-wire mistake, hit twice already (R-262's golden, and the OOB fixture in hub
+v0.99.0).
+
 **S-38 — A FACT ONE SIDE EMITS AND THE OTHER CANNOT RECEIVE IS A DEFECT, AND A CHECK NOW SAYS SO
 (2026-08-08, G-1 / R-260 / R-247).**