fix(fuse): a folder whose mkdir is queued is listed from the database (B125)

docs/BUGS.md

@@ -1344,7 +1344,7 @@ profile fails on it when it comes up, which depends on timing.
 
 ## B125 — A folder made offline fails with `EIO` once its listing is invalidated
 
-**Status:** Open.
+**Status:** Fixed.
 **Found:** 2026-10-03, by the simulation runs (`sim::run`, profile one-client-flaky, seeds 3
 and 4). Right after a restart, `rmdir y` (seed 3), and a write to a file in the client's folder
 (seed 4), failed with `EIO`. The daemon logged "enumerate folder children failed" with Drive's
@@ -1362,8 +1362,17 @@ uid. Drive answers 404, and every lookup in the folder fails with `EIO` until it
 Right after it lands, Drive may not list the new folder yet (the lag of B118). Then the listing
 fails with a 404 for the real uid too.
 
-**Test:** the simulation runs count it and go on. With `PDFS_SIM_KNOWN=fail` the flaky profile
-fails on it.
+**Fix.** A folder still known by its stand-in is listed from the database and never asked of
+Drive. Until its mkdir lands the folder is only here; once it has, the database holds what Drive
+does. The second case, a listing by the real uid that Drive does not show yet, needs a create
+that landed without being read back: the read-back waits up to 1.25 s for Drive to list the
+folder, longer than the lag of any simulation profile. The runs keep counting both until they
+show neither again.
+
+**Test:** `a_folder_whose_mkdir_is_queued_lists_after_a_refresh` in
+`crates/pdfs-fuse/src/sim/daemon.rs`: with sync paused, a folder is made with a file in it, a
+refresh drops its listing, and it is listed again. With `PDFS_SIM_KNOWN=fail` the flaky profile
+fails on it in the simulation runs; seeds 3 and 4 no longer reach it since phase 3.
 
 ## B124 — After a replacing rename fails, the file it was replacing is gone from the mount
 

docs/CHANGELOG.md

@@ -86,6 +86,8 @@ by its local id, in the queue, the stored tree and pins alike.
 - **A file read just as it reaches Drive no longer reads empty** (B179).
 - **Stopping the daemon no longer takes 10 seconds more than it needs** when an idle upload
   worker missed the stop (B180).
+- **A folder made while offline or with sync paused no longer fails with "Input/output
+  error"** once it is refreshed or the connection comes back (B125).
 - **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 B180.
+- Fixes from the simulation and account runs since then: B125, B127 and B141 to B180.
 - **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`.
 
@@ -89,8 +89,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          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). CI on 903452a passed every profile.
-   - [ ] Known-bug list in `sim/run.rs` is empty: B125 and B130 open; B127, B129 and B132 fixed
-         but unconfirmed.
+   - [ ] Known-bug list in `sim/run.rs` is empty: B130 open; B125, B127, B129 and B132 fixed but
+         unconfirmed.
    - [ ] A clean account run. The one on a6f36d5 (2026-10-04, LAN: 427 passed, 12 failed)
          failed B113 and B121 on every on-demand mount, two mirror-to-mirror move cases, and
          the journal check. B121 was a bug (B149, fixed); B113's case still expected creates