fix(fuse): list a file whose create lands while its folder is listed (B166)

A listing from Drive was overlaid with the queue as it was after Drive
answered. A create that landed in between was in neither, and a wide
folder on Wi-Fi dropped files that were never unlinked. The queue is now
read before Drive is asked too; a node that left it meanwhile is listed
as the DB has it.

docs/BUGS.md

@@ -12,6 +12,33 @@ Conventions:
 
 ---
 
+## B166 — A folder drops a file whose create lands while it is listed
+
+**Status:** Fixed.
+**Found:** 2026-10-04, by the account run on the working tree after B165 (a wide directory, on
+My files and on on-demand pairing 1): "concurrent unlinks left the wrong entries". Every
+create and all 64 trashes landed as they should, so the drain was right and the listing was
+wrong. The run logs no names. The simulation lost files that were never unlinked.
+
+**Where:** `list_children` in `crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** A folder whose listing was dropped is listed from Drive, then overlaid with what
+the queue still holds for it (B132). The queue was read after Drive answered. A create that
+landed in between was in neither: Drive had taken the listing before the node existed, and
+the queue had let go of it by the time it was read. The file was missing until the folder
+was listed again. On Wi-Fi, with 16 workers landing creates while the event feed drops the
+folder's listing, this happened in almost every run of the wide-directory case.
+
+**Fix.** The queued children are read before Drive is asked as well as after. A node queued
+before and gone from the queue after has landed meanwhile, and is listed as the DB has it
+now, under its name. One unlinked or moved away meanwhile is no longer a child of the folder
+in the DB, so it stays out.
+
+**Test:** `half_of_a_wide_folder_unlinked_at_once_leaves_the_other_half` in `sim/daemon.rs`
+(failed 4 of 4 runs before the fix, passed 8 of 8 after).
+
+---
+
 ## B165 — A stop waits on a stuck thread until systemd kills the daemon
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -59,6 +59,8 @@ by its local id, in the queue, the stored tree and pins alike.
   upload landed showed it both as Drive had it and as the queue did (B164).
 - **Stopping the daemon no longer hangs until systemd kills it.** A stop waits up to 10 s for
   work in progress, then exits and logs what was still running (B165).
+- **A folder no longer drops a new file while others are uploaded.** A file whose upload
+  landed while the folder was being listed was missing from that listing (B166).
 - **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 B165.
+- Fixes from the simulation and account runs since then: B127 and B141 to B166.
 - **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`.
 
@@ -101,7 +101,10 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          (2026-10-04: 260 passed, 3 failed) failed a new file that read back empty (B163,
          fixed), a 128-entry folder that listed 129 (B164, fixed), and its cleanup, which ran
          while the daemon was restarting: the stop waited on a busy thread until systemd killed
-         it (B165, bounded).
+         it (B165, bounded). The next run on the working tree (2026-10-04: 259 passed, 4
+         failed) found a wide folder dropping files whose create landed while it was listed
+         (B166, fixed). Still open from it: a new file that read back empty again, and a
+         cleanup that found no control socket.
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0