refactor: migration to event log backend for conversation storage

[Soulter]

Modifications / 改动点

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	astrbot-docs	bf4b31e	Commit Preview URL Branch Preview URL	Sep 13 2026, 04:21 PM

[sourcery-ai]

Sorry @Soulter, your pull request is larger than the review limit of 150,000 diff characters

[whatevertogo]

这里想讨论一下 parent_event_id 是否是当前需求必需的。我倾向于先采用「每个 Conversation 一条线性事件日志，fork 创建新 Conversation 并保存完整上下文基线」的方案。

事件记录可以简化为下面这样（为了阅读展开格式；JSONL 落盘时每个对象占一行，ID 使用短名称示意）：

{
  "seq": 14,
  "version": 1,
  "event_id": "b1",
  "created_at": "2026-09-14T12:01:00Z",
  "type": "context.rebased",
  "payload": {
    "reason": "compaction",
    "messages": [
      {
        "id": "summary1",
        "message": {
          "role": "user",
          "content": "此前用户询问北京天气，工具查询结果为晴，25°C，已回答用户。"
        }
      }
    ]
  }
}

这个方案下：

• message.appended 追加消息；context.rebased 用完整 messages 替换当前有效上下文，旧事件仍然保留。
• 恢复当前上下文时，从最近的完整 rebase 开始，按 seq 处理后续事件即可，不需要逐消息的父节点链。
• fork 在新 Conversation 中写入一份源位置的完整有效上下文，另外记录来源 Conversation 和事件位置供追溯。来源引用只表达出处，不成为恢复时必须访问的依赖。
• 编辑或回退可以追加新的完整上下文；需要保留可独立继续的旧分支时，则创建另一个 Conversation。

所以 "parent_event_id": "m2" 值得再权衡：fork 本身不必依赖它。AstrCodey 通过 SessionForked.messages 保存继承的有效消息；DeepSeek Harness 的 fork 则复制源事件前缀。这两种方式都不要求每条消息维护父节点。

当然，这不是说当前实现中的 parent_event_id 可以直接删掉：如果目标确实包括「同一 Conversation 内切换多条分支」或「跨 Conversation 共享祖先、避免复制上下文」，它就是有意义的，当前的 projection、leaf 选择和删除保护也依赖它。线性方案的代价则是 fork 会复制上下文，并把分支作为独立 Conversation 管理。

我的建议是先确认这两个目标是否属于本次必须支持的能力。如果主要需求是会话持久化、压缩和侧边对话，我更倾向上述线性方案；若共享祖先的分支树是明确需求，则保留父节点链。这个取舍与底层使用 SQLite 还是 JSONL 是两个独立问题。