docs: C6 destructive drill PASSED + R-23(a) evidence banked

C6: operator deleted the photos, EMPTIED THE TRASH, then restored through
the customer UI. 40 files placed (vs 6 in the non-destructive run) — the
files were really gone and really came back. 11 assets active, no schema
drift, timeline confirmed. Full UI path, no endpoint shortcuts.

R-23(a): the STOP-2 floor save turned out to be exactly the trigger. Hub set
the floor at 18:56:27 CEST; the controller logged 'wait woke: generation=1'
at 16:56:27 UTC — the same second — with the out-of-cycle report 2s later.
The wake is logged at DEBUG only, so it is invisible in docker logs and
lives only in the debug ring.

R-23(a) is NOT complete: the floor was set to a version the box already ran,
so nothing restarted and the restart-single-fire assertion is unexercised.

REPORT.md

@@ -217,6 +217,57 @@ a build+publish away — tracked under R-39, out of scope here.
 Build guest **9100 destroyed** (`pct destroy 9100 --purge`, all three LVs removed); only 9201
 remains on the host.
 
+## 4e. C6 — the DESTRUCTIVE customer-restore drill: **PASSED** (operator, 2026-07-20)
+
+This is the run that today's earlier reconstitute could not be: **data was genuinely destroyed
+first.** Operator deleted the photos in immich's own UI and **emptied the trash** (the step whose
+absence makes a drill prove nothing), then ran the restore from the customer-facing UI —
+„Teljes visszaállítás (fájlok + adatbázis)" on `/backups/restore`.
+
+```
+17:13:42  [offbox] immich: pre-restore safety dump written (49.6 MB)
+17:13:42  [stacks] Stopping stack: immich
+17:13:42  [stacks] Starting stack immich services only: [immich-postgres]
+17:13:43  [backup] Restore immich: replaying DB dump into immich-postgres (postgres)
+17:14:03  [backup] Restore immich: replayed 1 DB dump(s)          <- rc-0
+17:14:03  [stacks] Starting stack: immich
+17:14:27  [offbox] reconstituted immich from snapshot 49e7cb46:
+          40 file(s) placed, 1 DB dump(s) replayed, skewed=false
+```
+
+**`40 file(s) placed` is the proof of destructiveness** — the 15:40 non-destructive run over an
+already-good tree placed only 6. The files were really gone and really came back.
+
+Verified after: **11 assets `active`**, all four containers healthy, immich's own DatabaseService
+logged **`No schema drift detected`** (17:14:20), and the operator confirmed the photos are visible
+in the timeline. Full UI path, no endpoint shortcuts — the customer's own buttons.
+
+## 4f. R-23(a) — operator-UI save→apply round trip: **evidence banked** (2026-07-20)
+
+Not a task deliverable; captured opportunistically because the STOP-2 floor save happened to be the
+exact trigger R-23(a) needs, and the evidence was still in the debug ring.
+
+| Source | Time | Event |
+|---|---|---|
+| Hub (CEST) | 18:56:27 | `Global controller-version floor set to "0.153.0"` |
+| Controller (UTC) | **16:56:27Z** | `wait woke: generation=1 — firing out-of-cycle report` |
+| Controller (UTC) | 16:56:29Z | `Building system report` |
+
+`18:56:27 CEST` == `16:56:27 UTC` — **the same second**; the out-of-cycle report follows 2 s later.
+The ring also shows `wait baseline generation=0` at startup (baseline recorded WITHOUT firing, as
+designed) then `generation=1`, so the generation advanced past 0.
+
+**The wake is `logx.Debugf`, so `docker logs` at INFO shows nothing** — this evidence exists only in
+the debug ring (`GET /api/debug/logs?level=DEBUG`, never gated on `logging.level`). Anyone hunting
+for it in stdout will wrongly conclude the box did not wake. That is arguably R-23(b)'s complaint
+generalised: the Direction-2 path's most interesting moment is invisible at the default level.
+
+**Still unproven, and R-23(a) is NOT complete:** the **self-restart** leg. The floor was set to
+0.153.0 on a box already running 0.153.0, so there was no work to do and no restart — the
+"restart **single-fire**, no storm, once the generation has advanced past 0" assertion remains
+unexercised. Finish it by bumping the floor to a version the box does NOT yet run, with the debug
+ring open, and asserting **exactly one** restart.
+
 ## 5. NOT yet live-validated — remaining human/supervised work
 
 - ~~**STOP-1**~~ — **DONE 2026-07-20, PASSED.** See §4b for the log ordering, timestamps and the
@@ -226,14 +277,14 @@ remains on the host.
   (§4c). `GOLDEN_SHA256=15fdd191f3c660a60dc8651111053dd84281aeebc6c4c0f9ecdd3a87cb45a9d0`.
   Housekeeping left for whoever is next at the host: `pct destroy 9100 --purge`.
 - ~~**STOP-2**~~ — **DONE** (§4d). Golden 0.153.0 + floor v0.153.0 saved in the right order.
-- **Viktor's C6 customer-restore UI run — STILL OUTSTANDING, and it is the one that matters.**
+- ~~**C6 destructive customer-restore drill**~~ — **DONE 2026-07-20, PASSED** (§4e): trash emptied,
-  The 2026-07-20 reconstitute restored over an ALREADY-GOOD state (11 assets before, 11 after): it
+  restored through the customer UI, 40 files placed, 11 assets back, no drift.
-  proves the H4 window is closed and the operation is clean and non-destructive, but **nothing was
+- **R-23(a) — PARTIALLY banked** (§4f). Save→wake→report proven to the same second. **The
-  ever lost in it**. C6 needs the destructive shape — delete photos, **empty the trash** (deleting in
+  self-restart single-fire leg is still open**: bump the floor to a version the box does NOT run,
-  an app's own UI usually means trash, and a drill written that way merges 0 files, flashes success
+  with the debug ring open, and assert exactly one restart.
-  and proves nothing), then restore and verify the app's *content*, not the file count.
+- **R-48 — restore-page layout still janky** (operator-confirmed again 2026-07-20 during the C6 run:
-- **The R-23(a) operator-UI save→apply evidence** was not captured: nobody was watching the demo box
+  the overlong button row persists). Unchanged by this task and still the highest-value UX item on
-  wake during the manifest save. Cheap to bank on the next manifest save.
+  that page, since it is the finding that CAUSED the round-1 incident.
 
 ## 6. Observations (out of scope, recorded not acted on)