fix(fuse): end a mirror pass at the stop (B169)

A stop that came while a mirror pass was uploading let the pass go on to
the next level of folders until the stop gave up on it and the runtime's
end cancelled the uploads under it. Once the daemon is stopping, a batch
starts none of its waiting ops, lets the ones sending finish, and ends
the pass; the remote walk and a new pass stop too.

docs/BUGS.md

@@ -12,6 +12,32 @@ Conventions:
 
 ---
 
+## B169 — A stop lets a mirror pass go on until the runtime ends under it
+
+**Status:** Fixed.
+**Found:** 2026-10-04, in the journal of the account run on the working tree after B165. A
+stop that came while a mirror pass was uploading logged "background workers did not finish in
+time" for `pdfs-sync`, then "sync: task panicked … was cancelled" and a run of "no remote
+parent" warnings: the pass had gone on to deeper folders while the stop waited for it, and the
+runtime's end cancelled the uploads under it.
+
+**Where:** `flush_batch`, `walk_remote` and `reconcile_pass` in `crates/pdfs-fuse/src/sync.rs`.
+
+**Cause.** The mirror pass never asked whether the daemon was stopping. It sends its work a
+level of folders at a time and went on to the next level after the stop, until the stop gave up
+on it at its 10 s limit (B165).
+
+**Fix.** Once the daemon is stopping, a batch starts none of its ops still waiting for their
+turn, lets the ones already sending finish, and ends the pass. So do the remote walk and the
+start of a pass. The folder keeps the state it had before the pass; the next start's pass picks
+up from the baseline.
+
+**Test:** `a_stop_ends_a_mirror_pass_after_the_uploads_it_is_sending` in `sim/daemon.rs` holds a
+mirror upload, stops the daemon, then lets the upload through, and checks that the file in the
+deeper folder was not sent and the stop did not run into its limit.
+
+---
+
 ## B168 — A file removed with its folder while uploading is sent again, to the root
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -66,6 +66,8 @@ by its local id, in the queue, the stored tree and pins alike.
   took close to 2 s with 37,000 files at every start (B167).
 - **Files deleted with their folder while uploading stay deleted.** The mount no longer tries
   to upload them to the top of your Drive instead (B168).
+- **Stopping the daemon during a folder sync no longer waits for the sync.** The uploads in
+  progress finish, and the rest waits for the next start (B169).
 - **A file renamed just as its upload finished keeps its new name.** The mount no longer showed
   the old name, and a second rename no longer failed with "No such file or directory" (B152).
 - **A change that waits for a name to be freed no longer waits seconds after it is.** A rename or

docs/MILESTONE-3.0.0-STATUS.md

@@ -9,7 +9,7 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
 - **Phase 2**: local ids, inode = local id, one tree for every mount (2.10.0).
 - **Phase 3, first part**: mkdir, create, rename, unlink and rmdir on the mount are recorded
   locally and sent from the queue; `"local_first": false` brings back the old path (5e0f30c).
-- Fixes from the simulation and account runs since then: B127 and B141 to B168.
+- Fixes from the simulation and account runs since then: B127 and B141 to B169.
 - **Sync issues, first cut** (§6.2): refusals sorted into issues, shown at once in the app,
   tray and CLI; Export button and `pdfs sync export`; `pdfs sync issues`.
 
@@ -109,7 +109,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          running, which the run's queue wait takes for an empty queue (the script's side).
          Looking into it found the start spending 1.7 s rebuilding listings (B167, fixed).
          Its journal check caught a file removed with its folder while uploading being
-         sent again, to the root (B168, fixed).
+         sent again, to the root (B168, fixed), and a stop that let a mirror pass go on
+         until the runtime ended under it (B169, fixed).
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0