golden 0.232.0 baked, vouched, floor raised — and it carries TWO releases

GOLDEN_SHA256 5f8a53ed5b19a6cb2006298ce6239f6fca2b990cc3ef6eada89f602801ca91b8,
657 494 489 B. 0.231.0 was never baked, so the fleet went 0.230.0 -> 0.232.0.

THE CHECK THE 0.230.0 BAKE SKIPPED, AND THIS ONE DID NOT: the bake script's fingerprint was
compared ACROSS THE HOP - 7b0fb5cf...73b6a1 on DooPlex and inside the VM. The previous bake
recorded only the DooPlex-side hash and said so; this one is a measurement.

Three independent readers agreed before anything was vouched: the bake's own print, the round
trip of the published bytes (HTTP 200, 657494489 B, same sha, hashed from what was
downloaded), and the hub's Day-0 dropdown reading Gitea on a different code path. The
delivered artifact names its own controller - ./etc/felhom-controller-image reads
felhom-controller:0.232.0 - with 19382 entries under var/lib/felhom/docker/.

Both pre-gates were shown able to see something before their zeroes were believed, and the
manifest was RE-READ after vouching rather than trusted from the 303 flash.

DELIVERY WAS ACTUALLY EXERCISED. Both boxes had been hand-deployed during validation, so the
floor had nothing to move. Rather than report delivery untested, demo-felhom was rolled back
to 0.231.0 and the chain run for real - it moved itself in ~20s:
  10:47:16 controller-swap: image file written, restarting bootstrap  target=...0.232.0
  10:47:26 controller-swap: new controller healthy                    target=...0.232.0

And this is the first bake golden_currency_gate.py actually gates: it now reads the
GOLDEN_SHA256 line out of the bake log rather than matching a directory name (R-410, shipped
hours earlier the same day). All 13 felhom.eu gates are green, golden-currency included, for
the first time since v0.230.0 was released.

STATUS.md

@@ -1,8 +1,8 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-09-01 — I ran the week's six releases against each other overnight. Three things
-broke, none of them where I expected. The worst: the backup-content check I shipped yesterday
-CANNOT RUN AT ALL on a machine set up like `demo-felhom`, and it fails silently every night.**
+**Updated 2026-09-01 (second pass) — both faults from the overnight test are fixed, and the golden
+is baked, vouched and delivered. Both machines are on 0.232.0 and moved themselves. NOTHING is
+waiting on you.**
 
 **Earlier 2026-08-31 — I measured whether the box could test its own remote restore without you,
 then built the narrow version you picked. The measurement is why it is 3 seconds a night and
@@ -18,33 +18,26 @@ not an evening's work.**
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **The new nightly backup check does not work on `demo-felhom`** (R-414). It ran for the first
-   time on its own last night and could not start: that machine has no registered data drive, so
-   there is nowhere to unpack a backup to look at it. It will fail the same way every night, and
-   the only trace is one line in a log — the hub cannot tell it apart from a machine that never
-   had the feature. **Your backups there are fine** — the backup itself ran normally. It is the
-   CHECK that cannot run. **If you do nothing:** that machine, and any like it, silently never
-   gets the check. I have not changed anything; the fix is a small decision about where it should
-   unpack to, and it is yours.
+1. **Nothing is waiting on you.** Both problems the overnight test found are fixed and proven on
+   the real machines:
+   - the background job that could delete a live restore's lock now waits its turn — and the check
+     that finds the next one like it is a test, not a comment, so it cannot come back quietly;
+   - the nightly backup check now runs on `demo-felhom`. It said **pass** there this morning, on a
+     machine where it could not start at all yesterday.
+   The golden carrying both is baked, vouched, and the floor is raised. `demo-felhom` picked it up
+   **by itself in about 20 seconds**.
 
-2. **A golden carrying 0.231.0 is owed.** Golden **0.230.0** is baked, vouched and on both
-   machines. **0.231.0 is the build with the new nightly backup-content check**, and it is on
-   `demo-hp` only. **If you do nothing:** the check stays on one machine; a newly installed box
-   does not get it, and neither does `demo-felhom`. Nothing breaks — this adds a check, it does not
-   fix a defect. Baking and vouching 0.231.0 and raising the floor closes it, the same three-field
-   change as before.
-
-3. **Whether to keep the test app `bentopdf` on `demo-hp`.** I deployed it last night because it
+2. **Whether to keep the test app `bentopdf` on `demo-hp`.** I deployed it last night because it
    is the ONLY app of our 53 with neither a database nor stored files — which makes it the only
    way to prove the new check does not cry wolf on an app that legitimately has nothing. It
    passed silently, which is what we needed to see. **My pick: keep it**, as a permanent control.
    **If you do nothing:** it stays, using almost no space. Say the word and I remove it.
 
-4. **Nothing else about this release.** Everything in 0.231.0 ships in the controller image plus
+3. **Nothing else about this release.** Everything in 0.232.0 ships in the controller image plus
    two register lines in the hub (already live). No customer action, no data migration, no
    credential change.
 
-5. **Whether a documents-only push should still be checked for a missing golden** (R-404). We have now
+4. **Whether a documents-only push should still be checked for a missing golden** (R-404). We have now
    skipped that check **eight times**, each time for a written reason: it runs on every push to the
    website/documentation repository, including pushes that change nothing a machine installs.
    **A guard we correctly skip eight times is teaching us to skip it.**
@@ -56,11 +49,11 @@ nothing.*
    **If you do nothing:** nothing breaks, the skipping stays routine, and the count keeps rising.
    I have NOT changed it; this is yours to decide and mine to build.
 
-6. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
+5. **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
    it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.
 
-7. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
+6. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
    wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
    as it misled one by an hour.