R-1251 (P1): a pending put-back blocks every start — a cut restore's copy on an unbound drive waits (a restore hold), is poured back when the drive binds before any start; a failed put-back holds the app (H2); Stop during a restore still puts back (H7). Commit only, unreleased.

CHANGELOG.md

@@ -22,6 +22,35 @@ brief 2026-10-24, Part 4 (commit only; the release rides the next normal train).
   `…OnlyWhenTheAgentWaitsAndAnAppRuns`, `…QBLimitRuleSkipsAHeldLimit`, `…TheTwoAppsReadAndWriteTheirLimit`,
   `TestLineTestRunOutlastsTheClientTimeout`, `TestStartUpwatchRecoversTheHoldFirst`, `TestUpwatchHoldGetsBothAgentCalls`.
 
+### A pending put-back blocks every start (R-1251, P1; review round 2 HUNT-1 H1, H2, H7) — 2026-10-24 night, commit only
+
+- **A power cut during a restore of a drive-backed app no longer brings old data back later.** The restore's copy of
+  the live data lives on the app's drive; at start the drive was often not bound, Recover read the copy as „gone", the
+  boot recreate then started the app on the cut restore's data, and the next controller start poured the old copy over
+  everything written since. Now a copy that cannot be reached while its drive is not bound is WAITING: Recover holds
+  the app (`settings.HoldReasonPutBackPending`, the copy in `SafetyDump`; the household sees „hold.putback_pending")
+  and starts nothing. The hold is the one store every start path already honours — the household's
+  Start/Restart/Update, the boot recreate, the drive return, the media restart, the boot sweep, the night chain, the
+  update leg. When the drive binds, `AppStopGuard.ResumePutBack` pours the copy back FIRST (the boot recreate and the
+  drive-return restart call it before `appHeld`; the drive-return branch and the start run `ResumeWaitingPutBacks`
+  for held apps), lifts the hold, and only then may the app start. New `internal/backup/appstop_putback_wait.go`;
+  main.go wires `SetHolds(sett)` and `SetUndoReachable` (the copy is reachable while the app's `HDD_PATH` is a live
+  mountpoint) before Recover.
+- **A failed crash put-back leaves the app HELD (H2)** — the D20 hold (`HoldReasonRestoreMixed`, „stopped half-way"),
+  the copy kept, and the marker lets go of the app (the hold owns it) — never stopped-and-unheld, which Start or the
+  recreate would run and a later start would pour an old copy over. A copy that vanished while its drive is bound
+  holds the same way.
+- **Stop pressed during a restore no longer skips the put-back after a cut (H7):** the data is put back; the app stays
+  stopped as the household asked.
+- A removal clears a waiting put-back (it belongs to the install); a later restore that completes drops it (the
+  household chose that data; the copy stays on disk).
+- Tests (each seen failing with its rule taken out): `TestR1251_DriveCutRestoreWaitsForTheDriveThenPutsBackBeforeAnyStart`
+  (the review's lean-clone proof turned round), `…TheWaitingHoldRefusesEveryStartPath`, `…AFailedPutBackHoldsTheApp`,
+  `…AFailedResumeHoldsTheApp`, `…ACopyGoneWhileItsDriveIsBoundHoldsTheApp`, `…StopPressedDuringTheRestoreStillPutsBack`,
+  `…ADriveThatReturnsLaterIsPutBackThenStarted`, `…ACompletedRestoreDropsTheWaitingPutBack`; the wiring pins
+  `TestR1251_DriveStartPathsPutBackBeforeTheyStart` (web) and `TestR1251_MainWiresThePutBackWait` (main); the
+  removal row in `TestR704_ClearUpdateHoldClearsTheInstallsHoldsOnly`.
+
 ### Review round 2 (2026-10-24, unattended; commit only, no release) — two small fixes, each red-proved
 
 - **`REUSE.md` (docs only, same day):** D22's row no longer says „unreleased" (v0.338.0); the `recordInstalledImages`