[bug] SQLite scanRows torn-tail tolerance deletes valid events together with the bad row

[JZQiang]

Summary

When a bad row or seq gap appears after the last turn/end, scanRows marks that row and every row after it as torn (tornFrom = preserved.length), and commitRepair runs DELETE FROM events WHERE seq >= tornFrom — deleting valid events of the still-open turn that follow the bad row, then synthesizing only fake closers. One tail corruption discards more than the corrupted row.

Evidence

packages/session/session-persistence-sqlite/src/schema.ts:254-269:

for (let i = 0; i < rows.length; i++) {
  const p = parsed[i]
  if (!p?.ok || p.event === undefined) {
    if (i <= lastTurnEnd) throw new Error(...)   // bad row in committed region → error
    break                                        // after last turn/end → tolerated as torn
  }
  ...
}
return preserved.length < rows.length ? { preserved, tornFrom: base + preserved.length } : { preserved }

commitRepair (session-persistence-sqlite/src/index.ts:313-315): DELETE FROM events WHERE seq >= tornFrom — everything from the first bad row to EOF is deleted, including valid events of the current unclosed turn. JSONL's scanner also errors on committed-region gaps, but SQLite's branch treats everything after turn/end as deletable. SQLite transactions normally preclude bad rows (defensive branch), but manual edits / foreign tool writes / cross-version leftovers hit it.

Suggested fix

Torn tolerance should only cover the unclosed tail: keep consecutive valid rows after a gap (truncate at the gap, not to EOF), or restrict tolerance to strict EOF-truncation cases.

Verified at master 47f9438.

[zoahdev]

核验补充（对照当前 main HEAD 99f6f02，2026-08-17）：

• packages/session/session-persistence-sqlite/src/schema.ts:254-269 与 src/index.ts:313-315 与你引用的行号逐行一致，问题在当前 main 上仍然成立。
• tornFrom 目前只有唯一消费方：index.ts:269-274 的 load 路径（tornMarker → commitRepair），所以修复面很小，不会牵连其它读路径。

关于修复方向，我倾向你给出的第二选项（torn 容忍只覆盖"严格 EOF 截断"）：gap 之后还有有效行，更像是人工编辑 / 外部工具写入 / 跨版本残留，而不是崩溃尾部——这种情况报错（与 committed region 同策略）比静默删除更安全，因为删掉的是"看起来有效"的数据。代价是：真实崩溃后恰好又写入了有效行的场景（罕见）会从"静默修复"变成"报错"，但这类写入本身就是异常来源。

建议补一个回归测试钉住该语义：构造 [valid, valid, bad, valid, valid]（bad 位于最后一个 turn/end 之后、两侧均有有效行），断言修复后不会把后两行删掉——要么整体报错，要么只截断到 gap 前并保留其后有效行。