fix(fuse): list again when a listing changed while it was published (B159)

A lookup in the root publishes the "Shared with me" entry only if the root
listing did not change while its plan was read, and answered EAGAIN when it
had. Right after a restart the root is listed again as the first lookups come
in, so a write could fail with "Resource temporarily unavailable".
ensure_children now takes the listing again, up to four times.

docs/BUGS.md

@@ -12,6 +12,31 @@ Conventions:
 
 ---
 
+## B159 — A write right after a restart fails with "Resource temporarily unavailable"
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by the simulation's flaky-link profile (`one_client_on_a_flaky_link`,
+seed 4, one of ten runs on c2f9344). Half a second after the client restarted, a write into its
+folder answered `EAGAIN`, and nothing was logged. The folder was still a queued create.
+
+**Where:** `Core::ensure_children` in `crates/pdfs-fuse/src/lib.rs`.
+
+**Cause.** A lookup in the root also places the "Shared with me" entry. It reads that entry's
+plan from the database against a snapshot of the root listing, then publishes it only if the
+listing has not changed meanwhile, and answers `EAGAIN` if it has. Right after a restart the
+root is listed again while the first lookups come in, so a lookup could lose that race. Listing
+a shared folder answers `EAGAIN` the same way when a newer refresh overtook it. No caller
+retries, so the error reached the application.
+
+**Fix.** `ensure_children` takes a listing again, up to four times, when an attempt answers
+`EAGAIN`, and logs each retry at debug level.
+
+**Test:** unit test `a_listing_changed_while_published_is_taken_again`. A stress test with
+lookups and creates in the root at once did not hit the window (about 1,900 plans, none stale),
+so the race itself has no regression test.
+
+---
+
 ## B158 — A file renamed twice in a row ends up under the first name, again
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -46,6 +46,8 @@ by its local id, in the queue, the stored tree and pins alike.
   lost Drive's answer to reading back the file's last upload** (B157).
 - **A file renamed twice in a row, while the first name was still taken, keeps the second name**
   (B158).
+- **Opening a file right after the daemon restarts no longer fails with "Resource temporarily
+  unavailable"** (B159).
 - **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 B158.
+- Fixes from the simulation and account runs since then: B127 and B141 to B159.
 - **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`.
 
@@ -82,7 +82,9 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          again after its create lost its answer (B156, fixed). With sixteen drain workers
          (16fca10), seed 4 failed every replay on a write after an upload that was not read
          back (B157, fixed). Seed 3 then failed four of ten runs on two renames of one file
-         landing out of order (B158, fixed).
+         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).
    - [ ] 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)