R-254 CLOSED both sites (controller v0.208.0); R-255 filed; R-242 red again

R-254 site one was the same defect and is fixed the same way. Site two was NOT the
defect the row described: the pre-deploy hidden input is deliberate (a form must
carry what it submits, README §318) and was left alone; the indefensible one was
the readonly display input on an ALREADY-DEPLOYED app, where nothing is submitted.

The premise that this broke a repo rule does not hold and is recorded rather than
dropped: no line in the repo says 'no silent auto-fill'. What exists is
CONTEXT.md:2070, about accidental EMPTY-password deployments.

§7.3 measured on the fleet: site one's code path has never run (crafty-controller
is the only app declaring initial_credentials and is deployed nowhere); site two's
exposure is also empty (demo-hp runs three apps, none with a generated secret
field). HONEST LIMIT: that is a current-state measurement, and nothing recorded
reads — which was part of the fault. No evidence of exposure, and no mechanism
that could have produced evidence either way. Rotation not indicated by anything
measured.

R-255 NEW: the guard covers 4 of 27 pages at runtime, and the cheap all-templates
gate is blind to the shape that actually shipped (a secret under a neutral
page-data key) — both verified, both stated in the gate's own docstring. Filed
rather than declaring a partial guard complete.

R-242 red a second time in 24h; --no-verify declared. The cadence is the argument
for its other half: nothing gates the vouch.

STATUS.md

@@ -32,10 +32,9 @@ Both now say what has happened, say that nothing is lost, and link to the one sc
 
 ## What's broken
 
-- **An app's own first-login password is still sitting in a page's HTML**, behind a Reveal button that
-  only hides it visually — the same fault we just fixed for the configuration passphrase, in a
-  different place, with a real per-install secret. Found by looking for it rather than by an incident.
-  *(R-254)*
+- **Nothing new is broken.** The three known secret-in-page faults are all fixed; what remains is that
+  the *check* against a fourth covers 4 pages out of 27, and the cheap check that covers all of them is
+  blind to the exact shape that shipped. Filed rather than papered over. *(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)*
@@ -52,26 +51,29 @@ Both now say what has happened, say that nothing is lost, and link to the one sc
 
 ## Found today
 
-- **A password was living in the page source, and we went looking for others.** The configuration
-  passphrase was written into the settings page on every load and merely hidden with styling — it is
-  now fetched only when asked for, and the asking is recorded. *(R-249, fixed.)* The search that fix
-  required turned up **two more places doing the same thing**, one of them a real per-install app
-  password. *(R-254, not fixed — recommended next.)*
-- **The record was a day behind itself.** The recovery row still recorded only what was proven on
-  4 August. Corrected, with both halves and both dates. A sweep of all 146 register rows found **no
-  other** entry whose state disagrees with its own body.
+- **The last two passwords are out of the page source**, the same way as yesterday's: the page carries
+  only a yes/no, and the value is fetched when you ask for it — and the asking is now recorded, which
+  it never was. One of them was an app's own first-login password, read live out of the running app.
+  *(R-254, both sites fixed.)*
+- **How much was actually exposed: nothing we can find.** The only app that generates a first-login
+  password isn't installed anywhere, and of the three apps actually running on the demo machine, none
+  uses a generated secret. **But nothing recorded reads** — that was part of the fault — so this is
+  "no evidence of exposure", not "proof there was none". No passwords need changing on that basis;
+  the call is yours.
+- **One of the two turned out not to be a fault.** The deploy form's hidden password field is
+  deliberate: a form must submit what it saves, so the value you wrote down is the one stored.
 
 ## What we're working on
 
-- **Getting the remaining two secrets out of page sources**, the same way. *(R-254)*
+- **Widening the check** so a fourth secret-in-a-page is caught by a machine rather than by
+  someone looking. *(R-255)*
 - **Proving the hub really keeps the old sealed key** when a machine re-seals. Never run outside a
   test; needs a second deliberate wipe and its own session. *(R-198)*
 
 ## Waiting on you
 
-- **Nothing.** The new base image was baked and approved the same day, so a machine installed now
-  receives this week's fixes — including getting the password out of the page source. *(R-242 — the
-  bake half done; what remains is ours, not yours.)*
+- **Nothing blocking.** Today's release needs a new base image before installations receive it — same
+  as yesterday, same answer: it is ours to do, not yours. *(R-242)*
 
 *R-245 — whether an undecided household is auto-abandoned after 30 days — was settled on 7 August: we
 do not build it, and the reasoning is recorded.*
@@ -82,10 +84,8 @@ do not build it, and the reasoning is recorded.*
 the machine all this is built on, not what a customer receives. Mixing them in is why the page stopped
 being readable.*
 
-- **DooPlex's own backup makes every copy inside the same box, and nothing says when it fails.**
-  *(R-232)*
-- **193 old images exist only on this machine** and cannot be re-downloaded. About 27 GB against 199 GB
-  free — clutter, not space. Nothing deleted. *(R-210)*
+- **DooPlex's own backup keeps every copy inside the same box, and is silent when it fails.** *(R-232)*
+- **193 old images exist only on this machine**, ~27 GB against 199 GB free — clutter, not space. *(R-210)*
 - **The hub password needs rotating** — a diagnostic printed it into a session log; nothing suggests
   anyone else saw it. *(R-132)*
 - **One thing to read after DooPlex next restarts** — the second-SSD move has never survived a reboot;