controller v0.241.0: a bind-data app leans on off-site before its own unit; the hold names what the copy holds (R-479)

Operator ruling 2026-09-13. An app with classified binds walks second
drive -> off-site -> own unit (its unit holds no files); volume apps keep
2 -> 1 -> 3. RestoreHold.CopyHolds records what the chosen copy holds and
the sentence ends with it; older holds keep their tier-only sentence.
Tests on both halves; red-proof: a layout-blind order fails the bind case.

controller/README.md

@@ -579,6 +579,10 @@ second drive (Tier 2), the app's own recovery unit (Tier 1, „helyi"), off-site
 a 15 s bound — unreachable counts as absent, with a WARN; since v0.240.0 it runs no per-app `stats`). `update.backup_max_age` applies to whichever
 tier is chosen. An app with no copy anywhere is backed up first. Tier 2 is required nowhere in the
 update path; the backups page's „Teljes visszaállítás" still reads the Tier-2 predicate alone.
+**Since v0.241.0 (R-479) an app whose data is bind-mounted files walks second drive → off-site → own
+unit** (its unit holds settings and database dumps, not the files), and the hold sentence ends with
+what the chosen copy holds („… — ez a másolat csak a beállításokat és az adatbázist tartalmazza, a
+fájlokat nem." / „… a beállításokat, az adatbázist és a fájlokat tartalmazza.").
 
 **The sequence.** With no fresh copy on any tier the app is backed up first (`RunAppBackupNow`: this
 app's DB dump, volume dump, unit capture, then a Tier-2 copy whose failure is only a WARN — the unit