fix(fuse,core): adopt a twin holding the create's bytes (B127); trash the node of a withdrawn create that lost its answer (B151)

A retried create now adopts the file its lost answer made when Drive's
SHA-1 matches the staged blob, not only when the file is empty. A delete
after a sent create keeps the op as a trash that finds and trashes the
node that create may have made; a new create of that name waits for it.
The simulation's settle now reads the log, so known damage is explained.

docs/BUGS.md

@@ -12,6 +12,29 @@ Conventions:
 
 ---
 
+## B151 — A file deleted after its create lost its answer stays on Drive
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by the simulation's Wi-Fi profile in CI (`one_client_on_a_slow_link`,
+seed 2). `x/a.txt` was made, written and deleted within a third of a second. The queues never
+drained, and Drive kept `x/a.txt` with the bytes of its create.
+
+**Where:** `drop_doomed_ops` in `crates/pdfs-core/src/db/ops.rs`, and `Core::drain_trash` in
+`crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A create that times out may still have made the file; only its answer was lost (as in
+B127). The create stays queued with a backoff. A delete before the retry dropped the queued create
+as if nothing had been sent, so the node Drive had made kept the deleted file's name and bytes.
+Only a create on the wire at the time of the delete was turned into a trash (B129), and when that
+create failed, the trash took it as never made.
+
+**Fix.** A create that was sent, on the wire or before, becomes a trash that keeps the create's
+folder and blob. The drain looks in that folder for a node under the create's name that the
+create would have adopted (B127): made around when it was queued, and empty or holding the
+blob's bytes. It trashes that node, and then discards the blob. A new create of the same name in
+that folder waits for the trash. Sim test
+`a_file_deleted_after_its_create_lost_its_answer_leaves_drive`.
+
 ## B150 — A conflict copy whose folder is gone retries forever
 
 **Status:** Fixed (unverified).
@@ -559,7 +582,7 @@ profile fails on it when it comes up, which depends on timing.
 
 ## B127 — A file created offline lands twice when the answer to its upload is lost
 
-**Status:** Open.
+**Status:** Fixed (unverified).
 **Found:** 2026-10-03, by the simulation runs (`sim::run`, profile one-client-flaky, seed 1).
 The upload of a queued create timed out after Drive had made the file. On the next attempt the
 drain logged "name is taken remotely; creating under a conflict name". Drive ended with the file
@@ -573,6 +596,10 @@ and, for a file, be empty. A queued create uploads its bytes in the same call, t
 (`upload_created_file`). So the node a lost answer leaves behind holds those bytes, is not
 adopted, and the file is uploaded a second time under a conflict name.
 
+**Fix.** A file is also adopted when Drive's SHA-1 of its content is that of the op's blob. The
+blob then counts as uploaded. Sim test `a_create_whose_answer_was_lost_lands_once`. A write that
+replaced the blob after the lost upload still forks a copy: the node holds the older bytes.
+
 **Test:** the simulation runs count it and go on. With `PDFS_SIM_KNOWN=fail` the flaky profile
 fails on it when it comes up, which depends on timing.
 

docs/CHANGELOG.md

@@ -33,6 +33,10 @@ folder by local id too.
   for this release.
 
 ### Fixed
+- **A file deleted right after it was made no longer stays on Drive when the link lost Drive's
+  answer.** The node Drive made is trashed (B151).
+- **A new file no longer lands twice when the link loses Drive's answer to its upload.** The
+  file Drive made is taken as it is, instead of a second upload as a conflict copy (B127).
 - **A change to a file deleted elsewhere, together with its folder, no longer retries forever.**
   The conflict copy that keeps it now lands in the location's root (B150).
 - **`pdfs rename` and `pdfs move` right after a change through the mount are no longer undone.**

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 B150.
+- Fixes from the simulation and account runs since then: B127 and B141 to B151.
 - **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`.
 
@@ -43,12 +43,14 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
    and 100 folders on Wi-Fi against LAN (target: within 10 %).
    - [x] The measurement: `a_thousand_files_drain_as_fast_on_wifi_as_on_lan` in `sim/daemon.rs`,
          run with `PDFS_SIM_MEASURE=1`. It prints the times and asserts nothing yet.
-   - [ ] Baseline numbers, taken once the account run is done.
+   - [x] Baseline on eb1c105, three drain threads: the syscalls take 3.7 s on LAN and 4.3 s on
+         Wi-Fi; the drain takes 138 s on LAN and 938 s on Wi-Fi, 6.8 times as long.
 4. **Done-when checks**:
-   - [ ] Simulation passes on the Wi-Fi profile: `one_client_on_a_slow_link` is added, not yet
-         run.
-   - [ ] Known-bug list in `sim/run.rs` is empty: B125 and B130 open; B129 and B132 fixed but
-         unconfirmed.
+   - [ ] Simulation passes on the Wi-Fi profile: `one_client_on_a_slow_link` failed in CI on
+         seeds 2 and 3. Two bugs (B127, B151) and a harness gap: a settle did not read the log, so
+         it could not explain a known bug's damage. All three fixed; not yet confirmed in CI.
+   - [ ] 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)
          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