fix(fuse): queue pdfs rename and move behind the mount's changes (B149)

With changes through the mount queued, `pdfs rename` and `pdfs move` went
straight to Drive ahead of a rename the mount still had queued, which then
landed and put its name back: the account run's B121 case on every on-demand
mount. They are now queued whenever the mount would queue, or the node has
anything queued, and rewrite a still-queued create's target.

The B113 acceptance case no longer requires creates to reach Drive at once;
under local-first they are queued and the moves rewrite them.

docs/BUGS.md

@@ -12,6 +12,26 @@ Conventions:
 
 ---
 
+## B149 — `pdfs rename` or `pdfs move` right after a rename through the mount is undone
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by the account run on a6f36d5: the B121 case failed on every on-demand
+mount. After renaming and moving a file through the mount, it ran `pdfs rename` and `pdfs move`,
+and `pdfs ls` then showed the file in the right folder under the name the mount had given it.
+
+**Where:** `Core::rename` and `Core::move_to` in `crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** Since changes made through the mount are queued (local-first), the mount's rename was
+still in the queue when the CLI's requests came. Those went straight to Drive, landed first, and
+the queued rename landed after them and put its own name back. A file whose create was still
+queued could not be renamed by `pdfs` at all, since Drive does not know it yet.
+
+**Fix.** `pdfs rename` and `pdfs move` within a mount are queued whenever the mount would queue
+the same change, or the node has anything queued. The tree and the kernel are updated at once,
+as for a rename through the mount, and a taken name is refused up front. A node whose create is
+still queued has that create's target rewritten instead. A move between two locations still goes
+straight to Drive.
+
 ## B148 — A folder pinned before it has reached Drive loses its pin
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -33,6 +33,8 @@ folder by local id too.
   for this release.
 
 ### Fixed
+- **`pdfs rename` and `pdfs move` right after a change through the mount are no longer undone.**
+  They are queued behind it, and they work on a file that has not reached Drive yet (B149).
 - **A folder kept offline before it reached Drive stays kept offline.** Its pin was lost when the
   folder landed (B148).
 - **A queued change no longer holds up the queue forever on a link that stops answering.**

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: B141 to B147.
+- Fixes from the simulation and account runs since then: B141 to B149.
 - **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`.
 
@@ -49,8 +49,10 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          run.
    - [ ] Known-bug list in `sim/run.rs` is empty: B125 and B130 open; B129 and B132 fixed but
          unconfirmed.
-   - [ ] A clean account run. The last one (2026-10-04) failed on B70 (fixed as B145) and
-         mirror/mirror "busy syncing" (the script now retries); not confirmed yet.
+   - [ ] A clean account run. The one on a6f36d5 (2026-10-04, LAN, partial report) failed only
+         B113 and B121, on every on-demand mount. B121 was a bug (B149, fixed); B113's case
+         still expected creates to reach Drive at once and now accepts queued ones. Not
+         confirmed yet.
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0