fix(fuse): a stop queues the writes whose release the kernel never sent (B190)

docs/BUGS.md

@@ -12,6 +12,27 @@ Conventions:
 
 ---
 
+## B190 — A file saved just before the daemon stops can keep its old content on Drive
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-05, in the confirmation run on 2baad67 (`one_client_on_a_flaky_link` seed 9,
+about one run in three). A client wrote a 32-byte file and closed it, and the daemon was
+restarted at once. Drive held the file empty, and nothing was queued.
+
+**Where:** the stop in `crates/pdfs-fuse/src/mount.rs`, and `Core::queue_unreleased_writes` in
+`crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** `close(2)` returns before the kernel sends `release`, and the release is what queues
+a handle's bytes. The stop aborts the FUSE connection so that the unmount cannot hang, and the
+abort drops the requests the kernel still has queued. A release among them never reached the
+daemon. The file's create went out with what it held before the write, and the bytes went with
+the handle's scratch file. A handle a program still held open at the stop lost what it had
+written in the same way.
+
+**Fix.** Once every session has ended, the stop queues each write handle the kernel never
+released, as its release would have. Test `a_stop_keeps_what_a_handle_wrote_before_its_release`
+in `crates/pdfs-fuse/src/sim/daemon.rs`.
+
 ## B189 — A change that failed on a short outage waits out its retry long after the link is back
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -113,6 +113,8 @@ by its local id, in the queue, the stored tree and pins alike.
   (B187).
 - **Changes that failed during a short outage go out soon after the connection is back**, not
   after a retry delay of up to five minutes (B189).
+- **A file saved just before the daemon stops reaches Drive** with what was written. It could
+  keep its old content, or stay empty (B190).
 - **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,
   B172).

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: B125, B127, B130 and B141 to B189.
+- Fixes from the simulation and account runs since then: B125, B127, B130 and B141 to B190.
 - **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`; Discard button and
   `pdfs sync discard`; a warning badge on the node in the file browser.
@@ -115,7 +115,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          while open that lost the bytes its handle read (B186, fixed; older than 3.0.0).
          The run on 2baad67 found that a restart before such a file's trash went out queued
          its kept bytes again, for good (B188, fixed), and changes that sat out their retry
-         after an outage only the drain had met (B189, fixed; older than 3.0.0).
+         after an outage only the drain had met (B189, fixed; older than 3.0.0), and a file
+         saved just before a stop whose release the stop dropped (B190, fixed; older too).
    - [ ] A clean account run. The one on a6f36d5 (2026-10-04, LAN: 427 passed, 12 failed)
          failed B113 and B121 on every on-demand mount, two mirror-to-mirror move cases, and
          the journal check. B121 was a bug (B149, fixed); B113's case still expected creates