中断工具调用后重试会复用旧 seq，导致会话日志损坏无法打开（seq gap in committed region）

[yansdouble]

## 问题描述

当工具调用在执行途中被中断（interrupt/cancel），随后用户恢复会话并重试该工具时，重试产生的事件会**复用崩溃恢复占位事件的 seq**，而不是从 `lastSeq + 1` 继续。结果会话日志出现 seq 回退，下次加载直接失败，整个会话无法打开：

Error: corrupt session log: seq gap in committed region at line 1649
(expected 5259, got 5255)

## 复现步骤

1. 启动一个会话，让 Agent 执行一个耗时较长的工具（例如 `bash` 跑 `curl` / `sleep 30` 等几秒以上的命令）。
2. 工具执行到一半时中断当前 turn（取消 / 停止）。此时触发崩溃恢复路径 `interruptedTurnClosers()`，它会合成并持久化一批"关闭事件"：

tool/result (isError: "The tool call was interrupted...") → seq N
step/end → seq N+1
turn/end (reason: "interrupted") → seq N+2
session/end-seed → seq N+3

3. 恢复会话，让 Agent 重试同一个工具调用。重试得到的工具结果事件被写成了 `seq = N`（复用了占位事件的 seq），而不是 `N+4`。

## 预期行为

重试事件应继续严格递增的 seq 序列（`seq = lastSeq + 1`），即重试的 `tool/result` 应该是 `N+4`，保持日志单调递增、可正常回放。

## 实际行为

重试事件复用了 `N..N+3` 四个 seq，产生 seq 回退。下一次加载时，`SessionLogScanner` 在 committed region 检测到 seq 断层即抛 `seq gap`，会话无法打开。手工修掉这个 seq 断层后，还会连锁触发下游投影层的错位：

- `surface replace: start seq ... not found in surface`
- `sourceEventSeqs must include every shadowed surface node; missing ...`
- `token surface: replace ... has no adjacent shadow price (armed claim covers ...)`

## 实测到的损坏 seq 序列（来自一个真实损坏的 `session.jsonl.zstd`）

index 5254 seq=5254 tool/call (工具开始)
index 5255 seq=5255 tool/result isError=true ← 崩溃恢复占位
index 5256 seq=5256 step/end
index 5257 seq=5257 turn/end (interrupted)
index 5258 seq=5258 session/end-seed
index 5259 seq=5255 tool/result isError=false ← 重试：seq 复用 5255 ✗
index 5260 seq=5256 step/end ← 复用 5256 ✗
index 5261 seq=5257 step/start ← 复用 5257 ✗
index 5262 seq=5258 assistant/chunk ← 复用 5258 ✗
index 5263 seq=5259 assistant/chunk ← 从此之后 seq = index - 4

正确的应该是：重试的 4 个事件为 `5259..5262`，之后所有事件 `seq == index`。

## 环境

- `@deepseek-ai/dsh` 0.1.0-rc.7 / 0.1.0-rc.8
- `@deepseek-ai/dsh-session` 0.1.0-rc.8
- `@deepseek-ai/dsh-session-persistence-jsonl` 0.1.0-rc.8
- `@deepseek-ai/dsh-token-meter` 0.1.0-rc.8
- 存储压缩：zstd（多 frame 拼接）

## 根因分析

`Session.append()` 里 `seq = this.log.length`，并强制 `seq === index` 的连续契约（`SessionLogScanner.consumeEventLine` / `assertSessionEventEnvelope` 都在校验）。所以正常 append 流程不可能产生回退。回退只有在「重试路径使用了恢复前的 stale seq 计数器」时才会发生。

具体链路：

1. 中断时最后 turn 是 open turn（写了 `turn/start`、没写 `turn/end`）。
2. 下次加载时 `interruptedTurnClosers()` 扫描 tail，合成 error `tool/result`、`step/end`、`turn/end{interrupted}`，并让 backend durably commit 这批合成 closers。
3. resume 后重试工具时，重试路径似乎使用了一个 **resume 之前 / 合成 closers 之前**的 seq 值（即原 `tool/call` 被记录时的 seq N），而不是 resum 后 live `log.length`，于是又写出了 `N..N+3`。

另一个相关点：`interruptedTurnClosers()` 合成的占位 `tool/result` 是 `surfaceOp: "append"`。如果重试结果也以 `append` 进入 surface（而不是 replace 掉那个中断占位），同一个逻辑工具调用就会在 surface 上留下两个节点——这正是修掉 seq 断层后还会出现 `sourceEventSeqs` / token-meter 投影错位的原因。

> 附：仓库内设计笔记 `.agents/notes/rejected/simplification/2026-06-20-truncate-interrupted-turns.md` 讨论了这套「合成 closers」机制，但方案最终被 rejected（保留现有机制），因此该 bug 在最新 tag `dsh-v0.1.1-rc.2` 中仍然存在（我对比过 rc.7 → rc.2 的源码，`interruptedTurnClosers` 的 `seq = last.seq + 1`、`Session.append` 的 `seq = this.log.length`、closers 的 `surfaceOp: 'append'` 均未改变，207 个 commit 中也无针对此回归的修复）。

## 建议修复方向

1. **让 resume/重试路径严格从 live `session.log.length` 派生每一个新事件的 seq**（统一走 `Session.append`），不要使用缓存或中断前的 seq 计数器。
2. **考虑把「中断后重试」的结果表示为对中断占位 `tool/result` 的 surface replace**（同 callId），而不是再 append 一次，避免同一逻辑工具调用在 surface 上留下重复节点。
3. **（防御性）** 加载时检测到 committed-region seq 回退时，除了报当前 line/seq 冲突，再识别是否为「interrupted-tool-retry」模式（周围事件符合 `session/end-seed` 后紧跟同 callId 的 `tool/result`），以区分「瞬时崩溃产物」和「真实损坏」，给用户更可操作的提示。

## 临时恢复手段（供参考）

已成功恢复损坏会话：把 4 个重试事件 renumber 为 `N+4`，将其后所有 seq 值 +4，并同步 +4 修正所有 surface 引用（`surfaceOp.start/end`、`sourceEventSeqs`、`compaction/prune` 的 `shadowedRange/shadowedSeqs`），再按「首帧一行 header、每事件独立 frame + checksum」重建 zstd 文件。这印证了损坏纯粹是 seq 计数器回退，而非数据丢失。

[nokkies]

#4662 is this bug, with a fuller reconstruction and a published fix branch — worth reading together with this thread.

The piece that thread supplies, and which is hard to see from a single log, is that two processes are involved rather than one. Your timeline reads naturally as "the retry reused old seqs", but the events after the closers — tool/result → step/end → step/start — are the original in-flight turn continuing, not a retry. One process recovers the session and commits the synthetic closers while the other, still live, later commits the same tool call's real result starting from its own cursor.

Each validates its batch against its own in-memory cursor (appendCore checks event.seq === state.cursor + i) and the JSONL backend coordinates nothing across processes, so both "pass" and both append. The session subsystem docs already name the gap: tolerating concurrent writers needs a signal beyond the log.

That also explains why this is hard to hit deliberately and then suddenly reproducible: it needs one DSH_HOME open in two live instances. Starting a second dsh web inside a GUI session as a desktop wrapper is the shape that does it, and an interrupted turn on top makes the collision near-certain.

The fix on #4662 serializes appends with a cross-process writer lock and, while holding it, requires the batch to continue the durable tail — rejecting a stale-cursor append with a diagnostic rather than writing overlapping seqs. Reject-never-repair is the right call: a process whose cursor is behind must resume the session, not patch the file.

I have that branch running and it holds; review notes, including a performance fix for the tail read, are on that thread.

[yansdouble]

非常感谢你的回复，我了解了 #4662 所做的事情，桌面端跟web端确实同时打开，但我并没有关注桌面端的输出，非常感谢，我会关注 #4662 的恢复情况