perf(fuse): rebuild the hydrated listings in one pass (B167)

The hydrate rebuilt each listed folder's listing with a pass over every
entry. With 4,600 listed folders and 37,000 entries that took 1.7 s at
every start before the mount came up; one pass grouping the entries by
parent takes 3 ms.

docs/BUGS.md

@@ -12,6 +12,32 @@ Conventions:
 
 ---
 
+## B167 — The mount takes seconds to come up on a large Drive
+
+**Status:** Fixed.
+**Found:** 2026-10-04, looking into the cleanup of the account run on the working tree after
+B165, which found no control socket after the last daemon restart. Every start in that run
+took 2 to 3 s from "mounting" to "hydrated metadata cache from db" (37,000 nodes), the one
+before the cleanup 8.8 s. That was not the cleanup's failure: the socket is bound before the
+hydrate, and a request made during it waits. The cleanup ran some 1.5 s after the restart,
+before the new daemon got as far as binding it. `pdfs status` reports a daemon that is not
+listening yet as not running, and the run's queue wait took that for an empty queue.
+
+**Where:** `hydrate` in `crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** The hydrate rebuilt the listing of every listed folder with a pass over all
+entries: 4,600 listed folders times 37,000 entries. That took 1.7 s on an idle machine
+(measured on a tree of that shape with entries of the real size), before the mount came up.
+
+**Fix.** The listings are gathered in one pass over the entries (`listed_children`), which
+takes 3 ms on the same tree.
+
+**Test:** `hydrated_listings_hold_each_folders_live_children` in `lib.rs`: each listed folder
+gets its live children, the root is not listed inside itself, and an unlisted folder gets no
+listing.
+
+---
+
 ## B166 — A folder drops or empties a file whose create lands while it is listed
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -62,6 +62,8 @@ by its local id, in the queue, the stored tree and pins alike.
 - **A folder no longer drops or empties a new file while others are uploaded.** A file whose
   upload landed while the folder was being listed was missing from that listing, or listed as
   empty (B166).
+- **The mount comes up faster on a large Drive.** Rebuilding the folder listings from the cache
+  took close to 2 s with 37,000 files at every start (B167).
 - **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 B166.
+- Fixes from the simulation and account runs since then: B127 and B141 to B167.
 - **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`.
 
@@ -104,7 +104,10 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          it (B165, bounded). The next run on the working tree (2026-10-04: 259 passed, 4
          failed) found a wide folder dropping files whose create landed while it was listed
          (B166, fixed), or listing one empty: the new file that read back empty again
-         (B166 too). Still open from it: a cleanup that found no control socket.
+         (B166 too). Its cleanup found no control socket because it ran 1.5 s after the
+         last restart, before the new daemon had bound it: `pdfs status` reports that as not
+         running, which the run's queue wait takes for an empty queue (the script's side).
+         Looking into it found the start spending 1.7 s rebuilding listings (B167, 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