REPORT: record the PASSED restore round-trip (mount_parity ok, source_tier pbs)

REPORT.md

@@ -84,6 +84,22 @@ demo-hp      local age=498s    felhom-pbs age=2346s    both due:false
 Before v0.103.0 every one of those would have said "no successful backup recorded yet" and triggered
 a redundant backup — on the offsite tier, a multi-hour upload.
 
+## The restore round-trip — PASSED (demo-hp, 2026-07-26)
+
+```
+source_archive : felhom-pbs:backup/ct/9201/2026-07-26T15:42:42Z
+source_tier    : pbs        <- the v0.100.0 fix; the earlier attempt said "local" and died at 600s
+pass           : true
+verified       : boot+running
+mount_parity   : ok         <- mp0=/var/lib/docker 50G, mp1=/mnt/sys_drive 20G, mp8/mp9 stand-ins
+duration       : 4m5s       (restore + boot + verify + teardown)
+```
+
+`mount_parity` is the non-hollow half — a boot-only verify cannot see a missing data volume. The
+scratch tore down **cleanly** (no 403, no leak), confirming that the teardown 403 was a **phantom**
+(a short-timeout consequence, as `06-offsite-connectivity.md` already recorded) and correcting my
+earlier framing of it as a standing privilege gap.
+
 ## Tests
 
 `go build ./... && go vet ./... && go test ./...` — **rc=0, 29 packages**, vet run unpiped.
@@ -104,5 +120,7 @@ arc.
    is never automatically restore-tested — arguably the more important half of "is the DR tier real?".
 2. The agent does not report per-tier **cadences**, so the hub must infer "PBS ⇒ weekly" from storage
    type.
-3. The boot+verify half of the restore round-trip has not run under the fixed code.
+3. The **unattended** offsite restore-test — the scheduled path still only selects the primary tier.
+   (The manual/selftest round-trip is now PROVEN: `pass:true`, `verified:"boot+running"`,
+   `mount_parity:"ok"`, `source_tier:"pbs"`, 4m5s, clean teardown on demo-hp.)