Golden 0.226.1 baked, vouched, and the fleet floor raised — the debt is paid

golden_currency_gate.py had been CONVICTED four times today across three
controller releases. One bake covers all three, and the gate went red -> green
on the same command, which is its proof that it measures something real. THE
THREE DECLARED BYPASSES ARE NOW HISTORICAL RATHER THAN STANDING.

  GOLDEN_VERSION  0.226.1
  GOLDEN_SHA256   70ed8e9377dec22a9b493e55f222b0e25a49d7f3caec8c506e0412fd6baefe69
  size            657 197 592 B
  baked           gitea.dooplex.hu/admin/felhom-controller:0.226.1
  MinAgent        0.129.0  (read from the controller CHANGELOG header, not assumed)

THE EVIDENCE IS THE ROUND TRIP, NOT THE BUILD LOG. The published bytes were
downloaded back -- size and sha256 both identical to what the bake reported --
and ./etc/felhom-controller-image was read OUT of the downloaded archive:
`felhom-controller:0.226.1`. That is the delivered artifact naming the
controller it will start, from the bytes a customer's box would actually fetch.

Acceptance markers counted, not eyeballed, each string captured from this run's
own log rather than paraphrased from the runbook (two of the three the runbook
named until R-233 could not match anything the script prints): docker OK
(overlay2 = 1, including mount point rootfs = 1, mp0 = 1, upload OK (HTTP 201) =
1; excluding = 0, FATAL = 0, mp1 = 0. The 404 pre-gate passed before the run, so
nothing was overwritten.

THE VOUCH IS A THREE-FIELD CHANGE AND ALL THREE WERE CHECKED: agent_version
0.130.0 >= min_agent 0.129.0, so NOT the R-216 shape; wrapper_sha256 carried
through explicitly because the handler clears it when omitted. Verified by
RE-READING the manifest rather than trusting the flash -- golden option 0.226.1
SELECTED, all four shas matching.

THE FLOOR IS PROVEN ACTING, NOT MERELY SET. demo-felhom self-updated within 30
seconds: "[selfupdate] Post-update startup: update successful (0.225.0 ->
0.226.1)". Both demo machines now run 0.226.1 and only one of them was deployed
to by hand.

Token hygiene: copied file->file, read inside the VM by a runner script, never
on a command line (systemctl show ... | grep -c -F token = 0). THE LEAK GREP ON
THE COMMITTED LOG WAS PROVEN TO WORK BEFORE ITS 0 WAS BELIEVED -- a throwaway
copy with the token appended grepped 1, was shredded, and only then was the real
log's 0 taken as evidence.

Teardown: build guest 9100 destroyed --purge, secrets shredded AFTER the log was
copied out (standing rule 5), VM powered off, disk reverted to virgin.

R-242's OTHER half is untouched and still open: nothing gates the VOUCH itself.

STATUS.md

@@ -12,17 +12,14 @@ hub deployed itself; nothing is waiting on you except the floor from the last re
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **Bake and vouch a golden carrying controller 0.226.0, then raise the floor to 0.226.0** — Hub →
-   Configuration: the Day-0 artifact manifest first, then the global floor box. **Three controller
-   releases have gone out since the last golden bake** (0.224.0, 0.225.0, 0.226.0) and the vouched
-   golden still carries **0.223.0**, which is also where the floor sits.
-   **If you do nothing:** a machine installed today receives 0.223.0 and none of the three fixes, and
-   existing boxes are never required to move — `demo-hp` runs 0.226.0 only because it was deployed to
-   by hand. `demo-felhom` is on 0.225.0. This is tracked on **R-242**, which also records why the
-   `felhom.eu` push that shipped 0.225.0 used `--no-verify`.
+1. **Nothing — the golden train is current again.** Golden **0.226.1** was baked, published,
+   round-trip verified, vouched, and the fleet floor raised to 0.226.1 on 2026-08-30. Both demo
+   machines run 0.226.1; `demo-felhom` reached it by self-update, not by hand. A machine installed
+   today receives 0.226.1 and every fix from the four releases of 2026-08-30.
+   Evidence: `documentation/tests/golden-0.226.1-2026-08-30/`.
 
-2. **Nothing else.** Everything in the three releases is a fix to code that ships in the controller
-   image; no customer action, no data migration, no credential change.
+2. **Nothing else.** Everything in the four releases of 2026-08-30 is a fix to code that ships in the
+   controller image; no customer action, no data migration, no credential change.
 
 3. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
    Not in git, not in any saved file — in the log on this machine. **If you do nothing:** it stays as