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/README.md

@@ -570,22 +570,31 @@ job, and answers **202**. The page polls `GET /api/stacks/{name}`.
 **Refused with 409 before anything moves:** held; a backup, restore, app-data op or quiesce holding
 the app; a migration; already updating; deploying; not enough memory for the NEW template's request
 (the deploy's own `memoryVerdict`, releasing the app's current request); less than **2 GB** free on
-the Docker data root (a fixed floor — image sizes are not known without a registry query); and **no
-restorable backup** (no openable Tier-2 recovery unit with a proven copy).
+the Docker data root (a fixed floor — image sizes are not known without a registry query); and — since
+v0.239.0 — **no copy on any backup tier AND no way to take one now** (drive unresolvable, disconnected,
+or a migration running).
 
-**The sequence.** A proven copy older than `update.backup_max_age` is refreshed first
-(`RunAppBackupNow`: this app's DB dump, volume dump, unit capture, Tier-2 copy). Then a database
+**Any backup tier counts (v0.239.0, R-475).** The update leans on the first FRESH copy in the order
+second drive (Tier 2), the app's own recovery unit (Tier 1, „helyi"), off-site (Tier 3, looked up with
+a 15 s bound — unreachable counts as absent, with a WARN). `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.
+
+**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
+just captured is marked proven current, so a quiet app's own unit counts as fresh). Then a database
 safety dump, then the pin moves, then pull, `up`, and the health wait (`.felhom.yml` check, or 60 s of
 every container running for an app with none; bounded by `update.health_timeout`). **A failed pull
 puts the pin back. An app that does not become healthy is stopped and HELD** — the pin stays on the
-new version, and the hold sentence names the backup it can be restored from. A successful unit
-restore lifts an update hold.
+new version, and the hold sentence names the tier and the date of the copy it can be restored from
+(„második meghajtó" / „saját meghajtó" / „távoli mentés"). A successful unit restore — and, since
+v0.239.0, a successful off-site restore — lifts an update hold.
 
 **Config (`controller.yaml`):**
 
 ```yaml
 update:
-  backup_max_age: 24h   # a proven Tier-2 copy older than this is refreshed before the update
+  backup_max_age: 24h   # the chosen copy (any tier) must be younger than this, or the app is backed up first
   health_timeout: 5m    # how long the new version has to become healthy before the app is held
 ```