fix(fuse): do not send a file removed with its folder again (B168)

A delete of a file whose create was on the wire withdraws the create into
a trash. When its folder was removed too and that trash landed first,
Drive refused the create, and the drain re-homed the deleted file in the
root; only its missing bytes stopped it. The withdrawn create's trash
then read the trashed folder back into the cache before finding nothing
to trash.

A withdrawn create is no longer re-homed, and its trash is done once the
folder it was sent to is trashed or gone.

docs/BUGS.md

@@ -12,6 +12,38 @@ Conventions:
 
 ---
 
+## B168 — A file removed with its folder while uploading is sent again, to the root
+
+**Status:** Fixed.
+**Found:** 2026-10-04, by the journal check of the account run on the working tree after B165:
+"re-interned an authority missing from the local tree; retrying uid=local~151607". The wide
+directory case removed its folder while three of its files were still on their way to Drive.
+The folder's trash landed first, and Drive refused the three creates (422). The drain then
+logged "parent folder is gone remotely; creating in the root instead" for each, and failed
+only because the deleted files' bytes were gone. The trashes the deletes had queued then
+found the folder missing from the tree and read it back from Drive.
+
+**Where:** `create_local_node` and `resolve_unknown_authority` in
+`crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A delete of a file whose create is on the wire turns the create's op into a trash,
+which later looks in the create's folder for a node the create may have made (B151). The
+create's own failure path did not look at that: a create refused because its folder is gone
+is re-homed in the root (for a folder trashed on another device), deleted file or not. And the
+trash's access check asks about that folder, whose row the folder's own trash had removed, so
+it read the trashed folder back into the cache, deferred, and only then found nothing to trash.
+
+**Fix.** A create a delete withdrew is not re-homed. A withdrawn create's trash whose folder
+is trashed or gone is done: Drive took the node it was looking for along with the folder. It
+used to record a sync issue when the folder was gone for good.
+
+**Test:** `a_file_removed_with_its_folder_while_uploading_stays_removed` in `sim/daemon.rs`
+holds the file's create on its way to Drive until the folder's trash has landed, then checks
+that nothing was sent to the root and the folder was not read back (each fails without its
+half of the fix). `FakeClient::hold_next_create` is new for it.
+
+---
+
 ## B167 — The mount takes seconds to come up on a large Drive
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -64,6 +64,8 @@ by its local id, in the queue, the stored tree and pins alike.
   empty (B166).
 - **The mount comes up faster on a large Drive.** Rebuilding the folder listings from the cache
   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).
 - **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 B167.
+- Fixes from the simulation and account runs since then: B127 and B141 to B168.
 - **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`.
 
@@ -108,6 +108,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          last restart, before the new daemon had bound it: `pdfs status` reports that as not
          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).
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0