fix(fuse): never adopt a node we trashed as an unanswered create's twin (B162)

A folder removed and made again met the old folder while its trash was on
the wire and adopted it, so the new folder's contents went into the old
one and were trashed with it. The twin search now skips hidden nodes, as
listings do.

The fake Drive can hold a trash (hold_next_trash).

docs/BUGS.md

@@ -12,6 +12,32 @@ Conventions:
 
 ---
 
+## B162 — A folder removed and made again at once loses what goes into it
+
+**Status:** Fixed.
+**Found:** 2026-10-04, by the simulation's slow-link profile (`one_client_on_a_slow_link`,
+seed 4). The client removed folder `z` and made `z` again, with `z/x` and `z/x/y` inside. All
+three stayed in the mount but never reached Drive. The log showed the new `z` "adopting" the old
+one.
+
+**Where:** `Core::adoptable_twin` in `crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A create that finds its name taken looks for a node an earlier, unanswered attempt
+of its own made (B127), and adopts it. The old folder's trash was still on the wire, so Drive
+refused the new folder's name, and the listing showed the old folder, not in the tree any more
+and made a moment ago. The new folder took it for its own twin. What went into the new folder
+was created in the old one, and the trash then took it all along.
+
+**Fix.** The twin search skips nodes this mount trashed (its `hidden` set), as listings already
+do. The create then waits for the trash to free the name (`name_is_held`), or takes the name
+at once if the trash has landed (B144).
+
+**Test:** simulation test `a_folder_made_again_while_the_old_one_is_trashed_is_a_new_folder`
+(failed before the fix: Drive ended up empty). The fake Drive can now hold a trash
+(`FakeClient::hold_next_trash`).
+
+---
+
 ## B161 — A file moved while it was being created shows up under its old name
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -51,6 +51,8 @@ by its local id, in the queue, the stored tree and pins alike.
 - **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 folder removed and made again at once keeps what goes into it.** It used to be created
+  inside the removed folder and was trashed along with it (B162).
 - **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 B161.
+- Fixes from the simulation and account runs since then: B127 and B141 to B162.
 - **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`.
 
@@ -87,6 +87,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          fixed). Slow-link seed 4 also had folders reach Drive 30 s late, after the
          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).
+         Seed 4 failed on a folder removed and made again, whose create adopted the removed
+         folder (B162, 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)