fix(fuse): keep a move that lands while its create is read back (B161)

adopt_real_uid asked whether a move was queued only after reading the
node back. A move that landed in between left no op, and the answer still
had the old name, so the mount showed the file under it. Ask first.

The fake Drive can hold a read's answer (hold_answer_to_next_read) so the
test can land the move while the answer is on its way.

docs/BUGS.md

@@ -12,6 +12,31 @@ Conventions:
 
 ---
 
+## B161 — A file moved while it was being created shows up under its old name
+
+**Status:** Fixed.
+**Found:** 2026-10-04, by the simulation's slow-link profile (`one_client_on_a_slow_link`,
+seed 3). A file written and then moved at once ended up on Drive as `y/z/d`, but the mount
+showed it as `y/z/c.bin`, its name before the move, and `d` was missing.
+
+**Where:** `Core::adopt_real_uid` in `crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A move made while a file's create is on the wire waits in the queue until the create
+lands. Once the create is retired, the drain reads the new node back from Drive and adopts it.
+The tree keeps the name the user gave only while the move is still queued. The drain asked
+about that after the read-back. On a slow link the move could land in between: the answer
+still had the old name, and the move was no longer queued, so the old name won.
+
+**Fix.** The drain asks whether a move is queued before it reads the node back. It still asks
+again under the tree's lock (B152).
+
+**Test:** simulation test `a_file_moved_while_its_create_was_on_the_wire_keeps_its_new_name`
+(failed before the fix: the new folder listed nothing). The fake Drive can now hold a read's
+answer, taken when the read arrives, until the test releases it
+(`FakeClient::hold_answer_to_next_read`).
+
+---
+
 ## B160 — A new folder reaches Drive only half a minute later
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -49,6 +49,8 @@ by its local id, in the queue, the stored tree and pins alike.
 - **Opening a file right after the daemon restarts no longer fails with "Resource temporarily
   unavailable"** (B159).
 - **A new folder reaches Drive at once**, not up to half a minute later (B160).
+- **A file moved while it was still being uploaded keeps its new name in the mount** on a slow
+  link (B161).
 - **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 B160.
+- Fixes from the simulation and account runs since then: B127 and B141 to B161.
 - **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`.
 
@@ -85,7 +85,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          landing out of order (B158, fixed). Flaky-link seed 4 failed one of ten runs on a
          lookup that answered `EAGAIN` while the root was listed again after a restart (B159,
          fixed). Slow-link seed 4 also had folders reach Drive 30 s late, after the
-         drain's idle poll (B160, fixed).
+         drain's idle poll (B160, fixed). Slow-link seed 3 failed on a file moved while its
+         create was on the wire, which the mount showed under its old name (B161, fixed).
    - [ ] Known-bug list in `sim/run.rs` is empty: B125 and B130 open; B127, B129 and B132 fixed
          but unconfirmed.
    - [ ] A clean account run. The one on a6f36d5 (2026-10-04, LAN: 427 passed, 12 failed)