Register + architecture for controller v0.226.0 (R-353/357/358/360/396), and R-395 fixed

Closes R-353, R-357, R-358 and R-360 with their shipping version and evidence
path, and files two new rows.

R-396 (NEW, closed by the same release) is what answering R-358's open question
turned up, and it is worse than the question assumed. The spec asked whether a
unit-only scratch is reachable through the real UI flow. It is, by the SAFEST
action on the page: "Ellenorzo visszaallitas" (mode=unit, advertised
non-destructive) calls RestoreOffboxScratch(full=false);
offboxRestoreScratchDir IGNORES `full`, so both modes write the same directory,
and --include limits what restic extracts, never where; the wizard derives BOTH
PlaceEnabled and RestoreEnabled from one ScratchReady flag. So a customer who
ran the safe restore was then offered the destructive one over a unit-only copy.
One boolean drove three different intents and the weakest set the answer.

R-395 (filed by the spec) is fixed in this commit, not just recorded. STATUS.md
said golden 0.223.0 / floor 0.222.0 in one block and demo-hp 0.219.0 / floor
0.218.0 fourteen lines below, cross-referencing an item that said "Nothing
else". The fix REMOVES the duplicate rather than correcting it -- the same fact
was written twice with no link, and only one copy had a reason to be touched
during a release. "What works" now points at the item above instead of restating
a version.

07-backup-architecture: four rows added to the 10.2 gap register plus R-396.
Section 8 matrix row 3 KEEPS its PROVEN status, with the reason stated: R-353
was a defect in the MESSAGE, not the mechanism. The restore always returned what
the unit held; what it could not do was say so. A status that measures whether
data comes back must not move because a status line was wrong.

00-capability-map: one new row, and it splits what is claimed. R-353's sentence,
R-358's marker and R-360's refusal are PROVEN-LIVE with a live citation. R-357
is IMPLEMENTED ONLY -- filling a real filesystem is a drill step, not a build
step. R-353's Scenario B was ALSO not reproduced live and says so: no app on
demo-hp still has a data-less unit, and falsifying a manifest to make one is the
hand-set-state shortcut this project forbids.

This push used `git push --no-verify`. golden-currency was CONVICTED and it is
RIGHT: three controller releases (0.224.0, 0.225.0, 0.226.0) and the golden
still carries 0.223.0. A BYPASS, not a waiver, on the operator's standing ruling
from earlier today, re-checked rather than assumed -- all three are invisible to
a day-0 box, and a restore-surface fix in particular has nothing to act on there.
The ground expires the moment a release changes first-boot behaviour. Tracked on
R-242; ONE bake carrying 0.226.0 covers all three.

STATUS.md

@@ -12,14 +12,17 @@ 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. **Raise the controller floor to 0.223.0** — Hub → Configuration, the global floor box, on its own.
-   You already vouched the golden (the hub reads `golden_version` 0.223.0), but the floor still reads
-   **0.222.0**, so the last step of that release is outstanding.
-   **If you do nothing:** boxes are offered 0.223.0 but nothing requires it, so a machine that misses
-   the offer stays on 0.222.0 — where an app stopped from outside is reported as if you stopped it.
+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`.
 
-2. **Nothing else.** This release changed only the hub, and the hub deploys itself through its
-   manifest. No golden, no vouch, no controller.
+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.
 
 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
@@ -41,7 +44,10 @@ nothing.*
 ## What works
 
 Both demo machines are home, healthy and reporting — agent **0.130.0** published and running on both.
-`demo-hp` runs controller **0.219.0**; the fleet floor is still **0.218.0** (see item 2 above).
+**Which controller each box runs, and where the floor sits, is item 1 above and is not restated here** —
+R-395: this paragraph carried a second copy of those numbers, it went stale by seven releases, and the
+page then disagreed with itself about the thing an operator checks first. Ask the hub (`/hosts`,
+`/configs`) or the box for what is live; a doc is never the authority on a version.
 Off-site is credentialed on `demo-hp` and its store opens with the machine's own key.
 
 **The fleet, because two summaries have been misread:** five customer records, three machines.