R-1251: sync the restore copy's folders before the marker names it (a cut left undo.json as .tmp on Tester 1); the interrupted-restore record says the put-back waits, not 'run it again'. Commit only.

CHANGELOG.md

@@ -42,6 +42,16 @@ brief 2026-10-24, Part 4 (commit only; the release rides the next normal train).
   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.
+- **The copy is on disk before the marker names it** (found by the live proof on Tester 1, 2026-10-24: a power cut
+  2.1 s after „the restore copy is recorded" left the 1.5 GB tar whole but the journal as `undo.json.tmp` — the rename
+  lived only in the page cache, the marker on the other filesystem was durable, and the start could not read the
+  copy; the new H2 hold kept the app stopped). `persistUndoForCrash` now syncs the copy's folders up to `backups/`
+  (`syncUndoDirs`) before `SetUndo`, and `atomicWriteFile` syncs the folder after its rename. Pinned by
+  `TestR1251_TheCopyIsOnDiskBeforeTheMarkerNamesIt` (seen failing with the sync removed).
+- **The household is no longer told to run the restore again while its put-back waits** — that would restore the backup
+  over the data the box is about to put back. The restore record (`PutBackWaiting`,
+  `note.restore.interrupted_put_back_waiting`) and the `restore_interrupted` event say the box puts the data back when
+  the drive is there. Pinned by `TestR1251_TheRecordSaysThePutBackWaits` (seen failing).
 - 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`