STATUS + capability map: narrow the end-to-end off-site claim to the leg it was proven on

The 2026-08-04 row claimed "a customer's file survives a machine rebuild and comes back
— the whole off-site story, end to end". Tonight's drill shows that holds for the
declared-userdata leg of a drive-declaring app and for nothing else: the off-site restore
has no named-volume leg (R-354), and refuses outright for the 40 apps that declare no data
drive (R-356). Since that class keeps ALL its data in named volumes, the end-to-end story
is unproven there and disproven for the volume leg generally. The escrow/key half of the
row is untouched and still stands.

STATUS.md also corrects the fleet pair it still named (0.214.0/0.129.0 -> 0.217.0/0.130.0)
and records that demo-hp's off-site had been silent since 9 August.

REPORT.md

@@ -393,10 +393,10 @@ over a unit that *did* have a data leg.
 | 22:39–22:45 | paperless-ngx → R-355 |
 | 22:51–22:57 | Part 4.3 damaged store; repo repaired |
 | 23:02–23:04 | Part 4.1b safety dump, both directions |
-| 23:10–23:12 | Part 4.5 full disk; Part 4.6 controller killed |
+| 23:10–23:13 | Part 4.5 full disk (both paths); Part 4.6 controller killed mid-restore |
 | 23:15 | Part 4.4 drive pulled |
-| 23:17–00:16 | Part 4.7 filesystem filled and freed |
-| 23:35 | abandonment countdown created (fires 05:10) |
+| 23:17–23:26 | Part 4.7 filesystem filled, backup reserve observed, filesystem freed |
+| 23:08–23:09 | abandonment set-aside store created; countdown written and controller restarted (fires 05:10) |
 
 **Steps off the customer's path, named:**