fix(fuse,core): count a new file's landing until its bytes are cached

A create that carries a file's bytes retired its op, then cached the
bytes and gave the tree the real uid. Nothing counted that window, so
`pdfs status` read empty while it ran, which B119 promises means the
file reads without the network.

A delete in that window found the placeholder uid in the tree and
trashed the node by its real uid. `queue_trash` asked the tree whether
that uid was open, found no entry, and dropped the cached bytes the open
handle reads. If the cache store ran at the same moment, its tag was
written after the eviction and never removed. CI caught that as a
stray .meta file.

The create's landing is now counted like an upload's, from the op's
retirement until the tree has the real uid. The delete and the replace
pass whether they found the file open. Opening the cache removes a tag
whose bytes are gone, which also covers a crash between an eviction's
two removals. The simulations wait for `Daemon::drained`, which counts
the landing, before they go offline.

B255 and B256 move to fixed: the account run checked both.

docs/CHANGELOG.md

@@ -11,6 +11,15 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
 
 ## [Unreleased]
 
+### Fixed
+
+- **A new file reads without the network as soon as `pdfs status` shows nothing queued**
+  (B257). A new file's upload counted as done before its bytes were cached, so a script that
+  waited for an empty queue and then went offline could not read it. A new file deleted while
+  open in that moment could also lose the bytes its open handle reads, which made a write or
+  read through that handle fail with "Input/output error". The cache also removes leftover
+  tags of evicted files when it opens.
+
 ## [3.6.0] — 2026-10-27
 
 Schema: **44**, unchanged.