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/internal/settings/settings.go

@@ -1615,6 +1615,10 @@ type RestoreHold struct {
 	// unit, 2 the second drive, 3 off-site. 0 means a hold written before the field existed; it keeps
 	// its original sentence (backup.UpdateHoldLegacyFmt). Only set for HoldReasonUpdateFailed.
 	CopyTier int `json:"copy_tier,omitempty"`
+	// CopyHolds (R-479, v0.241.0) is the customer phrase for WHAT the named copy holds — e.g. „a
+	// beállításokat, az adatbázist és a fájlokat tartalmazza" — recorded at hold time, because an app's
+	// data layout (bind-mounted files vs. named volumes) decides it and may not be readable later.
+	CopyHolds string `json:"copy_holds,omitempty"`
 }
 
 // Hold reasons. See RestoreHold.Reason.