Apps burndown (controller 0.321.0 released): R-1097, R-1102, R-1101, R-1095, R-1098 closed; R-1103 opened; build-hub.sh 1.25.0

build-hub.sh refuses an existing tag and an unanswered registry (test_build_hub_push_once.sh, red-proved).
Register 179 -> 175. R-1067 stays BLOCKED: Tester-2 reports 0.292.0. Design notes in 02 and 07; STATUS;
evidence audits/burndown-apps-2026-10-16/; REPORT-burndown-apps-2026-10-16.md.

Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/architecture/07-backup-architecture.md

@@ -553,6 +553,13 @@ a normal night: nothing. A box off for weeks: one catch-up when it returns; the
 running all along. An upgrade from an older release: the ledger is seeded, the first missed night after it is the
 first one made up.
 
+**[FACT, 2026-10-16, R-1097] An image's own anonymous VOLUME is in no backup.** The app backup takes the named volumes the
+compose DECLARES (`backup.ResolveDockerVolumeNames`) and the drive folders it binds; a path the image keeps in its
+`VOLUME` that the compose does not mount lands in an anonymous volume and is taken by nothing. Measured with RomM's saves
+(`/romm/assets`) on demo-hp; fixed with a named volume, and catalog gate `image-volumes` keeps a measured registry of such
+paths (`audits/burndown-apps-2026-10-16/P1/`). A survey of every running container on demo-hp found no other data path
+in an anonymous volume (PrivateBin's are temp folders).
+
 ### 6.2 Coverage per app class — and an unresolved count
 
 **[FACT]** Of 53 catalog templates, **52 keep data in Docker named volumes**; exactly **13** carry a