golden 0.206.0 VOUCHED; demo-hp's stale flag cleared; session report

VOUCHED with the operator's approval, verified from the stored hub_settings
rather than the flash: golden_version 0.205.0 -> 0.206.0, sha
c85230b42f53baa9c1ee9986ac312c751d6cbc29fbe070d87bb2214429a9108e.
agent_version and min_agent both stayed 0.127.0. wrapper_sha256 was carried
through explicitly, because the handler CLEARS it when omitted.

THE GATE WAS CONVICTED BEFORE THE BAKE AND IS OK AFTER IT - red to green on
the same command, which is its proof that it measures something real. It went
green on the BAKE, not the vouch; that limitation is stated in its docstring
and stays open on R-242.

THE STALE FLAG WAS WRONG AND IS CLEARED, with the operator's approval. One
row, identity-matched on host_id and guarded on stale_at IS NOT NULL;
changes() returned 1. Verified end to end, not just in the database: the hub
serves the hash again, the box recorded it at 11:10:19Z, and it is
byte-identical to the key that box is using - so shape (c) compares, matches
and correctly stays silent. The false warning is gone, PROVEN WITH A POSITIVE
CONTROL rather than an absent line: 0 escrow-confirm lines since the restart
while 5 scheduler lines in the same window prove the box was logging.

R-246 records the clearance and keeps the column ruling open: stale_at has NO
production writer, changes what a customer is told, and can be seen by nobody
who would look for it. Either give it an evidential setter or retire it.

STATUS.md finished at 87 lines (from 258). Waiting-on-you is now genuinely
empty: the base image is approved and live, and R-245 was re-filed as a
decision taken with quota as its reopening condition.

Session report: REPORT-clear-the-ground-2026-08-08.md - the six spike
questions each answered with method and measurement, Q4 said plainly (only a
database read), Q6 said loudly (a fresh box CANNOT reach this state, so the
next walk cannot meet it), and three observations noticed but not acted on.

STATUS.md

@@ -42,13 +42,15 @@ for byte identical — three separate times, including a filename with Hungarian
 
 ## Found today
 
-- **A leftover flag has been silently switching off the new recovery detection on one demo machine
-  since 4 August.** A Re-issue during the recovery drill set it, using code we removed the next day.
+- **A leftover flag had been silently switching off the new recovery detection on one demo machine
+  since 4 August — found, and cleared with your approval.** A Re-issue during the recovery drill set it, using code we removed the next day.
   **The flag is wrong** — the sealed package does cover the key that machine is using, and the two
   fingerprints match exactly. Because of it the hub withholds a figure the machine needs, so the
   machine tells its owner *"create a new recovery code"* — the one act that would put their old backups
   beyond reach. **A freshly installed machine cannot reach this state**, because nothing has set that
-  flag since 5 August. *(R-246, R-247, R-248)*
+  flag since 5 August. **Cleared the same day; the machine now compares its key correctly again.** What
+  is still owed is a ruling on the flag itself: nothing sets it, nothing can see it, and it changes
+  what a household is told. *(R-246, R-247, R-248)*
 
 ## What we're working on
 
@@ -59,8 +61,8 @@ for byte identical — three separate times, including a filename with Hungarian
 
 ## Waiting on you
 
-- **Approve the new base image**, so every future installation carries this week's fixes. *(R-239,
-  R-242 — presented separately in this session.)*
+- **Nothing.** The new base image was approved and is live — every future installation now carries
+  this week's fixes. *(R-239, R-242)*
 
 *Nothing else is pending. 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). It has been re-filed as a