fix(fuse): adopt a twin holding bytes an earlier attempt of the create sent (B156)

docs/BUGS.md

@@ -12,6 +12,26 @@ Conventions:
 
 ---
 
+## B156 — A file written again after its create lost its answer lands as a conflict copy
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by the simulation's Wi-Fi profile (`one_client_on_a_slow_link`, seed 4,
+two of six replays on e5f3f61). The create of `a.txt` timed out twice, but Drive had made the file
+with the bytes of the first write. A later write replaced the blob the queued create carried. The
+third attempt found the name taken and created `a (sync-conflict …).txt`; `a.txt` kept the old
+bytes.
+
+**Where:** `Core::adoptable_twin` and `Core::withdrawn_twin` in `crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A twin is adopted when it holds the bytes the create uploads (B127), and only the blob
+the op held at the retry was hashed. The twin held the bytes an earlier attempt sent.
+
+**Fix.** Each attempt records the SHA-1 of the blob it uploads, by op id, in memory. A twin holding
+any of them is ours. One holding older bytes than the op's is adopted, and the op's blob goes up
+as a revision of it. After a restart such a twin still forks a conflict copy, which loses
+nothing. Sim test `a_file_written_again_after_its_create_lost_its_answer_lands_once`; the fake
+Drive's held and lost create answers now combine.
+
 ## B155 — A write whose upload lost its answer lands as a conflict copy of itself
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -38,6 +38,8 @@ by its local id, in the queue, the stored tree and pins alike.
   no longer lands as a conflict copy, and the mount no longer shows that copy's name (B154).
 - **A change to a file no longer lands as a conflict copy of itself when the link loses Drive's
   answer to its upload** (B155).
+- **A file written again while its upload was being retried no longer lands as a conflict copy
+  of itself when the link lost Drive's answer to the first try** (B156).
 - **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 B155.
+- Fixes from the simulation and account runs since then: B127 and B141 to B156.
 - **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`.
 
@@ -64,7 +64,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          7269cb5 failed LAN seed 9, a regression from the B153 fix (B154), and Wi-Fi seed 2,
          a write whose answer was lost (B155). Both fixed. One slow-link run of seed 2 failed
          once with a rename answering `ENOENT` as a folder move landed. Not reproduced since;
-         it may be B152.
+         it may be B152. Replays of slow-link seed 4 failed two of six times on a file written
+         again after its create lost its answer (B156, 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)