Field incident

A session running on latest main-v2 (dce3b3a) forked a "conflict copy" 30 seconds after its first mid-turn autosave, with no second runtime involved (same writer_id/pid throughout):

• 17:59:02 first 30s mid-turn snapshot bootstraps the event log: 21 messages, revision 1. The transcript tail is an assistant message whose tool call was still running — a legitimately dangling call.
• 17:59:32 next autosave: memory holds 34 messages whose first 21 are byte-identical to disk (verified by per-message JSON hashing), i.e. a pure append — yet it was rejected as diverged and forked …-recovery-748ca7f3….

Root cause: checkSnapshotWrite compares the pending snapshot against LoadSession's view of disk, and load-time normalization had already fabricated a placeholder result for the dangling call (sessionToolResults). The live session's real tool result collides positionally with the placeholder, both prefix checks fail, and a pure append misreads as divergence. Any tool-heavy turn whose tool outlives the 30s autosave interval reproduces this deterministically.

Fixes (one per commit, same root cause family)

1. checkSnapshotWrite falls back to the raw transcript (09ce7df). LoadSession now preserves the pre-repair messages when normalization changed them; append shape, owned-rewrite ownership, and conflict-kind classification retry against the bytes actually on disk before declaring conflict. The mid-turn compaction rewrite variant (ownership revoked by the repaired digest) is covered by the same fallback.
2. Dirty-resume saves no longer take the append shortcut (a1fecd3). appendFrom was measured against the normalized view while the event log replays the raw transcript; the chain-broken append event was silently discarded on the next load, dropping the whole post-resume turn from disk despite a successful save. A pending repair now falls through to the full rewrite, which persists the repair and the new turn together. Same commit: SaveRecoveryBranch's "recovery not needed" coverage check gets the same raw fallback.
3. Recovery forks transplant the in-flight turn marker (7932bc1). The marker written at turn start stayed on the forked-from path; turn end cleared the (absent) marker on the recovery path. The next open of the original branch fired recoverInterruptedTurn against a turn that had completed on the recovery branch, stripping the transcript back to the turn boundary and force-saving the truncation.
4. Fork-orphaned markers self-heal on open (1437d5a). Every fork made by an older runtime already left such a marker behind. A recovery child whose parent_id is this session and whose created_at postdates the marker means the marked turn moved rather than died: clear the marker, keep the messages. A genuine crash (no such child) strips exactly as before. This is the migration path for existing users — no manual cleanup needed.

Tests

10 regression tests across internal/agent and internal/control; each was verified to FAIL with its fix stashed and PASS with it applied. Full go test ./..., go vet, gofmt clean.

Related

#6074, #6080, #6082 fixed the revision-CAS/ledger-drift/adoption conflict sources; this covers the normalization-induced ones they don't reach.