controller v0.239.0: any backup tier lets an app update (R-475)

Operator ruling 2026-09-13. The update precondition walks Tier 2, Tier 1
(own recovery unit, "helyi") and Tier 3 (off-site, 15 s bound; unreachable
counts as absent with a WARN) and leans on the first FRESH copy; the
backup_max_age rule applies to whichever tier is chosen. No copy anywhere:
back up first. Refused only when nothing exists and no backup can be taken.
RunAppBackupNow tolerates a Tier-2 failure (WARN) and marks the captured
unit proven current. The hold names the tier (második meghajtó / saját
meghajtó / távoli mentés) and the date; pre-v0.239.0 holds keep their text.
A successful off-site restore now lifts an update hold. The backups page
still uses Tier2UnitRestorePoint unchanged.

Scenarios G-M tested; red-proofs M, L, the tail and the off-site clear in
felhom.eu documentation/audits/rulings-r472-r475-2026-09-13/.

controller/internal/settings/settings.go

@@ -1598,6 +1598,10 @@ type RestoreHold struct {
 	// CopyDate is the RFC3339 time of the proven backup the customer is told they can restore from.
 	// Only set for HoldReasonUpdateFailed.
 	CopyDate string `json:"copy_date,omitempty"`
+	// CopyTier (R-475, v0.239.0) is WHICH backup tier CopyDate belongs to: 1 the app's own recovery
+	// 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"`
 }
 
 // Hold reasons. See RestoreHold.Reason.