R-239 CLOSED (golden 0.205.0 vouched); R-241 ruling into the map and STATUS

R-239: the operator approved the vouch this session. golden_version
0.203.0 -> 0.205.0 (+ derived sha); agent_version and min_agent both stayed
0.127.0, because the new golden's MinAgent is also 0.127.0 - so in the event
it was a ONE-field change, not three. wrapper_sha256 was carried through
explicitly: the handler reads it from the form and CLEARS it when omitted.
Verified from the stored hub_settings (WAL-aware copy), not from the flash.
The R-120 gate passed exactly - the newest controller the fleet reports is
0.205.0, so a 0.204.0 golden would have been refused.

R-241: the capability map's recovery-journey row and STATUS carry the spike's
ruling - a MINTING defect, not a screen-predicate defect. The row stays FAIL:
delivery is not a journey, and R-241 is diagnosed, not fixed.

R-242 and R-243 surfaced in STATUS in plain language.

STATUS.md

@@ -28,9 +28,29 @@ beautifully, with nobody touching anything — hands the machine a fresh key. Ho
 machine think it no longer needs rescuing. It is the same mistake the system already fixed once, one
 level higher up. *(R-241)*
 
-**And separately: today's machines do not yet have last week's fixes.** A machine installed tonight
-still gets the older in-house service, so two defects we fixed and closed are still live for a new
-customer. The code is right; it has not been packaged and approved yet. *(R-239)*
+**7 August — we asked which of two things was actually wrong, and the answer changes the repair.** The
+obvious reading was that the screen's rule was too narrow. It was not. **The screen was telling the
+truth**: there really was nothing openable with the key the machine was holding — because the machine
+had *made that key itself*, on top of the sealed package we were already keeping for it. Three things
+now measured rather than argued: the part that makes the key asks only *"is there a file here?"*,
+while the two neighbouring pieces of code both check first whether we are holding a package; the
+machine had that knowledge **half an hour before** it made the key, and it was the very reason the
+repair ran at all; and **the machine worked out the problem itself**, wrote *"the sealed package does
+not cover the current key"* into its own log thirty-five minutes before the household looked, and then
+threw the answer away. **So mending the screen would have hidden a machine quietly making its own
+backups unopenable.** No code was written — this was a question, and it is now answered. *(R-241)*
+
+**Two things we did not go looking for.** A machine in this state also **stops making off-site backups
+altogether, and nothing raises an alarm** — three separate safety nets each correctly decide it is not
+their business *(R-243)*. And the obvious repair has a trap: a household that has already said *"I do
+not want the old data"* would be asked again, forever, unless we record that they decided.
+
+**And separately: today's machines now DO get last week's fixes — approved 7 August.** The newer
+in-house service is packaged and approved, so a machine installed from now on gets both fixes a new
+customer was still missing last night. Existing machines are untouched, and the approval can be undone
+by re-selecting the previous one. *(R-239 — closed)* **The gap that let it happen is not closed**: a
+release that changes what a customer sees is still not *delivered* until it is packaged, and nothing
+checks that. *(R-242 — recorded, not built)*
 
 
 ## What's broken
@@ -44,11 +64,9 @@ customer. The code is right; it has not been packaged and approved yet. *(R-239)
   their new app. It did not, and the restore refused minutes later. The button now says plainly that
   it did not start anything.
 
-- **A machine installed today still gets the older in-house service, so it cannot open a recovery
-  package until you approve the newer one.** It is no longer *lied to* — it says plainly that the
-  machine cannot do this yet — but **approving the new service is one click from you**, and until then
-  such a machine also gets the cautious "we do not know why" wording rather than the helpful one.
-  *(R-216, R-223, R-224)*
+- **~~A machine installed today still gets the older in-house service~~ — RESOLVED 7 August.** The
+  newer service is packaged and approved, so a newly installed machine now gets it without anyone
+  touching the machine. *(R-216, R-223, R-224, R-239)*
 - **Three things a rebuilt machine still cannot do by itself.** Its owner cannot re-attach their own
   drives, so no app can be put back on its data; it cannot create a new recovery code at all; and the
   screen at the machine itself never stops showing a stale pairing code. Each is understood, measured