D62: restore copies kept 30 days, listed with their date, deletable by hand (typed name, never a needed copy, operator event); D63: a test-build-only fault switch for the R-1256 H4/H5 live proofs — tests red first

controller/README.md

@@ -1039,8 +1039,13 @@ Each app can define rich metadata in `.felhom.yml`:
     failed volume (never unpacked on top of the old content). An off-site restore whose definition write fails writes
     the LIVE definition back before the start, or holds the app. Every restore begins in one step with the check for a
     restore, the backup run and a second-drive copy (`TryBeginRestoreOp`, also both kept loads). A copy that nothing
-    needs (no hold of any kind, not named by the app-stop marker, no restore running) goes after 14 days, checked every
-    6 h (`restore_copy_sweep.go`; decided by CC unattended — operator may reverse).
+    needs (no hold of any kind, not named by the app-stop marker, no restore running) goes after 30 days, checked every
+    6 h (`restore_copy_sweep.go`; operator ruling D62, 2026-10-29).
+  - **Restore copies in the kept-copies list (unreleased, D62).** The restore page's „Megőrzött másolatok" lists each
+    restore copy: the app, the restore's date, the size, „automatikusan törlődik: <date>". „Törlés most" deletes one
+    earlier, after a warning naming the app and the date and the app's name typed (`POST /backup/restore-copy/delete`,
+    JSON; 409 while a backup/restore runs or the app updates). A copy a hold or a pending put-back needs: the button is
+    off, the reason on one line. Each delete: one log line and the operator event `restore_copy_deleted`.
   - **A restore cut by a power loss, on a drive that comes back late (unreleased, R-1251).** The copy of the live
     data lives on the app's drive. When it cannot be reached at start because the drive is not bound yet, the app is
     HELD (`putback_pending`; „…A visszaállítás előtti adatai egy meghajtón vannak, amely most nem érhető el…") and no