fix(fuse): a file replaced just as its create lands is trashed on Drive (B175)

docs/BUGS.md

@@ -12,6 +12,28 @@ Conventions:
 
 ---
 
+## B175 — A file replaced by a rename just as its create lands stays on Drive
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by `one_client_on_a_good_link` (seed 8) on 378667f, run three at a time
+in a loop. `rename b.txt -> a.txt` replaced an `a.txt` whose create had landed a few
+milliseconds before, and the next `rename a.txt -> d` moved the old `a.txt` on Drive. Drive
+ended with the old bytes in `d` and the new ones still in `a.txt`, and the queue did not drain.
+
+**Where:** `Core::remove_replaced` in `crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** The same gap as B173, through `rename`. The replace found the old file under its
+stand-in, found no op left to drop, and took it for a file Drive had never seen. So nothing
+trashed it on Drive, and the tree took it back under its name once it got its uid.
+
+**Fix.** As in B173: after dropping a stand-in's ops, the replace checks whether the node's row
+has a real uid. If it has, the file is trashed on Drive like any other replaced file.
+
+**Test:** `a_file_replaced_as_its_create_lands_is_trashed_on_drive` in
+`crates/pdfs-fuse/src/sim/daemon.rs`.
+
+---
+
 ## B174 — A file renamed just as its create lands is refused with "Permission denied"
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -76,6 +76,8 @@ by its local id, in the queue, the stored tree and pins alike.
   there, and the next file with that name no longer became a conflict copy (B173).
 - **Renaming a file just as it reaches Drive no longer fails with "Permission denied"**
   (B174).
+- **A file replaced by a rename just as it reached Drive is removed from Drive too.** It no
+  longer stayed there, and the next rename of its name no longer moved it instead (B175).
 - **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: B127 and B141 to B174.
+- Fixes from the simulation and account runs since then: B127 and B141 to B175.
 - **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`.
 
@@ -118,7 +118,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          while its upload was read back showed its old name again (B172, fixed). The loop
          on d850265 failed seed 12 once in nine runs: a file deleted just as its create
          landed stayed on Drive (B173, fixed). The suite on 378667f failed seed 6: a rename
-         in the same gap was refused with `EACCES` (B174, fixed).
+         in the same gap was refused with `EACCES` (B174, fixed). The loop on 378667f failed
+         seed 8: a file replaced by a rename in that gap stayed on Drive (B175, 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