Bug: 同一会话被两个 dsh 进程并发写入导致会话日志损坏（seq 撞号）

[LuRia-yzk]

Bug 报告：同一会话被两个 dsh 进程并发写入导致会话日志损坏（seq 撞号）

两个 dsh 实例（npm 版与源码版）共用同一 $DSH_HOME 并发写入同一会话，导致 session.jsonl.zstd 中两个事件撞上同一个 seq，resume 时报 corrupt session log: seq gap。

复现、预期与验收

• 复现步骤：
  1. 启动第一个实例：npx @deepseek-ai/dsh web（端口 3080）
  2. 启动第二个实例：pnpm dsh web --port 3081（共享同一 $DSH_HOME，默认 ~/.dsh）
  3. 两个实例都操作/写同一个会话
  4. resume 该会话 → 报错
• 实际结果：会话日志损坏，resume 失败。session/end-seed 与 agent/inbox/spliced 被分配了同一个 seq（47245），持久化层将其判定为 "seq gap"（expected 47246, got 47245），拒绝恢复。手动删除撞号事件后进一步报 invalid persisted inbox splice（insert/claim 是成对事件，删 insert 导致 claim 在空 inbox 上校验失败）。
• 预期结果：第二个实例无法写入同一会话（单写者保护），或至少大声告警；损坏时提供可用的修复工具。
• 环境：Windows 11，Node v24.13.1，pnpm 11.7.0；npx @deepseek-ai/dsh 0.1.0-rc.6 与源码版 0.1.0-rc.5（commit 47f9438）同时运行。
• 验收条件：
  1. 双实例并发写同一会话时，第二个写者被拒绝或告警，而不是静默写坏日志；
  2. 报错信息区分 seq 重复（撞号）与 seq 缺失（真 gap）两种情况；
  3. （建议）提供持久化层的 renumber/repair 工具，中段损坏可自动恢复。

根因分析

两个写者各自的 seq 计数器都走到了 47245，各写入一条不同事件。持久化层没有单写者保护：README 声明 "One live writer per session"，但没有任何机制阻止第二个进程写同一会话。这是并发写入，不是事件丢失——现有报错 corrupt session log: seq gap 把两种情况（event.seq < expected 撞号 / event.seq > expected 真 gap）混为一谈，误导排查方向。

修复过程（用户侧手动完成）

1. 用 harness 自带的 scanZstdFrames + decompressZstdFrame 逐 frame 解压（Node 内置 zstdDecompressSync 只解第一个 frame，多 frame 拼接流需自行逐帧解）；
2. 按文件顺序重新分配事件 seq（保留第一次出现的 47245，其后的 splice-insert 顺延为 47246，后续所有事件 +1）；
3. 未受影响的 frame 原字节保留，只重编码受影响的 frame（compressZstdFrame）；
4. 结果：48251 个事件全部保留，seq 连续，28 个 inbox splice 重放全部通过。

给团队的改进建议

1. 单写者保护：对会话文件加文件锁/租约/原子认领，第二个写者直接拒绝或大声告警，而不是静默写坏。
2. 报错信息误导：format.ts:364-373 两条分支共用一个 message，建议区分 seq 重复与 seq 缺失，便于定位是双写者还是丢事件。
3. 缺少修复工具：中段损坏属于硬损坏（README："A defect at or before the last committed turn/end is corruption and rejects"），无自动修复。建议提供持久化层的 renumber/repair CLI。
4. 双写者检测：append 时检测到 seq 与已有冲突并报警。