docs: DIAG round 2 — H1 confirmed, H4 found; two standing rulings landed

VERDICT. H1 confirmed: the reconstitution never ran. /backup/offbox/reconstitute
was never hit (reconstituted/safety-dump/replay line counts all 0); the operator
clicked the old missing-only button, which merged 34 files and left the DB
untouched. H2 rejected (the full path never executed; staging used the correct
snapshot 49e7cb46). H3 rejected (no replay happened; DB was genuinely asset:0).

R-44 is exonerated and working: 49e7cb46 carries offsite_run_id 20260719T102851Z
and its dump probes to asset:11 / user:1 — a properly coherent pair, against
round 1's asset:0 / user:0.

H4 (NEW, the more important result). Phase-3 recovery ran the real sequence and
the v0.148.0 path executed correctly — safety dump, stop, start, replay — then
the replay ABORTED: relation "clip_index" already exists. Proven to the second:
  10:58:25 controller begins replay
  10:58:33 immich-server "Reindexing clip_index" -> "Reindexed clip_index"
  10:58:35 dump's CREATE INDEX clip_index fails, exit 3
The replay races the app's own schema repair, because reconstitution starts the
stack before replaying (ImportDump needs a live container). The photos survived
only because pg_dump emits COPY data before CREATE INDEX — luck, not design. The
same start-then-replay shape is on the LOCAL path, so it is a class defect.

Recovery: PARTIAL and STOPPED as instructed. All 11 assets are back and visible
by every DB criterion (status=active, deletedAt null, all files resolve), but the
operation reported failure and immich reports schema drift. Not clean acceptance
evidence; no second attempt made; safety dump read only.

Findings -> R-47 (the replay race), R-48 (restore controls separable only by
layout — the proven cause of this incident), R-49 (1.1 GB of a 1.2 GB immich
backup is ML model cache + a postgres data-dir tar duplicating the .sql dump +
immich's own nightly dump; recorded, not changed).

RULINGS LANDED.
  - 00-capability-map.md:61 -> PARTIAL, scope-corrected: 6D's destruction hit the
    FILE TREE only; the DB survived in its named volume, so "end-to-end from
    offsite alone" overclaimed scope.
  - The 704.6 MiB "discrepancy" -> CLOSED, not a defect: it was immich's own
    Tarhely widget, never a controller page. Same for round 2's 650MiB->1.4GiB.
  - customer-restore row: partial evidence recorded, NOT flipped.

Diagnosis only — no code, label or layout changes; no forget/prune.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P9Nn14TWGzKoqAJAiVwC2s

documentation/audits/DIAG-immich-restore-2026-07-19.md

@@ -174,12 +174,16 @@ run. So on a normal box the offsite dump is never even staged to disk. Correct a
 15 MB, mtime 07-18 17:10, stranded by the immich 2→3 redeploy. The live DB has never known about
 it. Dead weight, not today's issue; worth a sweep policy for major redeploys.
 
-### 6. [LOW, unresolved] Storage figure discrepancy
+### 6. [CLOSED — not a defect] Storage figure discrepancy
 
 The brief cites **704.6 MiB** used on the library storage. Measured: **126 MB** total
-(`upload` 72 M, `encoded-video` 30 M, `backups` 18 M, `thumbs` 8 M). Not reconciled in this
-session. If 704.6 MiB came off a controller Storage page, that gap is its own defect and needs a
-separate look.
+(`upload` 72 M, `encoded-video` 30 M, `backups` 18 M, `thumbs` 8 M).
+
+**RULED 2026-07-19 (Viktor): resolved, no controller defect.** The 704.6 MiB came from **immich's
+own Tárhely widget** — immich-internal accounting — not from any controller Storage page. The two
+numbers measure different things and were never expected to agree. The same explanation covers the
+„650 MiB → 1.4 GiB" figure quoted during round 2, which likewise does not match the controller's
+measurement of the tree. Closed; no follow-up item.
 
 ### 7. [Method] A UI delete cannot test restore