v0.343.0: release header; README — fix A (stable start), fix B (.fab downloads first), D47 set-aside line

CHANGELOG.md

@@ -1,4 +1,4 @@
-## Unreleased (next: v0.343.0) — the line test for a box that seeds all day (R-1250) (2026-10-24) — committed, not released
+## v0.343.0 (2026-10-25) — a restore tells the truth, downloads first and never touches an earlier install's backup; the line test for a box that seeds all day (R-1250, R-1251–R-1253, R-1269–R-1271, R-1279; D47, D48, D49 = A) — tag pushed; global floor after the operator's yes
 
 **MinAgent: 0.158.1** (unchanged): an agent before 0.165.0 never reports `waiting_for_quiet`, so nothing is held. Attended
 brief 2026-10-24, Part 4 (commit only; the release rides the next normal train). Design: felhom.eu `08` §9.

controller/README.md

@@ -1029,13 +1029,23 @@ Each app can define rich metadata in `.felhom.yml`:
     restore failed and nothing changed (or, with placed files, that its database and volumes are back and the copied
     files stay); the operator gets `backup_run_failures` leg `restore-put-back`. Only a put-back that fails — or a
     replay AND rollback that both fail — still HOLDS the app (`restore_mixed` / the restore hold, operator-cleared),
-    and then the copy is kept for support. On success the copy is removed. `offbox_restore_undo.go`.
+    and then the copy is kept for support. On success the copy is removed — **since v0.343.0 only after a stable start** (fix A, R-1270 follow-up): the
+    verdict needs the stack running on every sample of a 45 s window, no container restart in it and every healthcheck
+    `healthy`; the copy then goes after a further 3 min of the same (10 s samples, watched up to 30 min; a new restore
+    of the app ends the watch). A restore whose app does not start reads „…még nem indult el…", keeps the copy and
+    alarms the operator once (D49 = A: nothing is poured back by itself). `restore_verdict.go`. `offbox_restore_undo.go`.
   - **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
     path starts it; when the drive binds, the copy is poured back FIRST, then the app starts. A put-back that fails
     holds the app for support („félúton megszakadt"). Stop pressed during the restore still gets the put-back. The
     copy's folders are synced before the restore records it. `appstop_putback_wait.go`.
+  - **A `.fab` import downloads first (v0.343.0, R-1279):** the bundle's images are pulled before step 1 (the same D48
+    helper as every restore); a version that cannot be downloaded refuses the import with the D48 sentence and the
+    running app and its volumes are not touched. `appexport/restore.go`.
+  - **A reinstall never writes into an earlier install's backup (v0.343.0, D47):** each install has an `install_id`;
+    a unit of another install is set aside whole (`backups/set-aside/<app>/<stamp>`), listed as a kept copy and
+    restorable; the operator gets one `backup_run_failures` line, leg `unit-set-aside`. `backup/unit_owner.go`.
   - **An export that stops its app waits for a running restore (unreleased, R-1253):** it is refused (409,
     „Egy másik művelet … éppen leállítva tart egy alkalmazást…") while another operation holds the app-stop marker.
   - **A broken backup block never deletes a second-drive copy (unreleased, R-1252):** the night copy deletes dest