[bug] JSONL torn-tail repair and concurrent append from two processes can truncate each other's live writes

[JZQiang]

Summary

materialize uses link()+EEXIST to stop two processes from clobbering each other's session files, but the append path has no cross-process coordination. When two dsh processes share a session root: process A appends zstd frames while process B's loadStored reads a half-written frame, produces a tornMarker, and commitRepair → truncate(path, tornStart) cuts the tail of a frame A is still writing — A's handle was opened before the truncate and keeps writing from the old offset → holes/interleaved frames → corrupt log.

Evidence

packages/session/session-persistence-jsonl/src/index.ts:651-701 (appendLines/repair), 436-444 (commitRepair), 543-556 (materializePosix link+EEXIST guard comment: "two processes materializing the same id concurrently cannot clobber each other"), 292-304 (readStableFile).

The single-process coordinator serializes per-id (coordinator.ts:1010-1033), but cross-process there is no such protection, while other code paths (link guard, assertStoredIdentity duplicate-id check) explicitly assume a shared root is a multi-process scenario.

Trigger

Two processes (or profiles) sharing one session root with concurrent activity on the same session id.

Suggested fix

Use O_APPEND single atomic write + file-level flock on the append path (aligned with materialize's cross-process guard), or verify the file revision hasn't changed since the read (reuse readStableFile's stat loop) before commitRepair truncates.

Verified at master 47f9438.