fix(streaming): 从本地数据库读取超大群聊历史

[Tyr1onX]

问题

Fixes #634。

真实测试确认：任务在第 1 批、已写入 0 条时就触发 NapCat/QQ Worker 重启并丢失登录态，说明失败发生在 QQ 原生历史请求内部，早于磁盘落盘、解析、资源处理和 ZIP 生成。

根因

旧群聊流式抓取依赖以下 QQ 原生历史接口：

• getAioFirstViewLatestMsgs
• getMsgsIncludeSelf/getMsgHistory
• getMsgsBySeqAndCount

其中 getMsgHistory 最终仍委托给 getMsgsIncludeSelf，并不是独立 fallback；getMsgsBySeqAndCount 在 NapCat 类型定义中已经标记为 deprecated。降低批次、串行化和禁止重试只能减轻压力，无法阻止第一次原生调用本身终止 Worker。

当前修复

1. 群聊流式导出改为本地数据库分页

群聊流式路径已完全移除上述三个原生历史入口，改为：

• MsgService.getLatestDbMsgs(peer, 1)：只从 QQ 本地消息数据库取得最新消息和 msgSeq；
• MsgService.queryMsgsWithFilterEx(...)：以 msgSeq 为排他游标向更早消息分页；
• 查询批次从 20 开始，连续成功后升到 50、100，最高 200；
• 每批至少间隔 250 ms；
• 游标必须严格向更早的 msgSeq 移动，否则立即停止；
• 回归测试明确禁止群聊流式路径重新出现 getMsgHistory 或 getMsgsBySeqAndCount。

2. 禁止并发和危险重试

• 所有群聊数据库查询共用一个全局串行信号量；
• 单次调用超时、bridge 或 Worker 异常后立即失败，不自动重复调用；
• 异常后熔断 30 秒；
• 开始前检查 bridge 与 QQ 登录状态。

3. 保留磁盘分块流水线

• 每批原始消息立即写入独立 JSONL 暂存文件；
• 内存只保留当前请求批次、当前解析批次和有限去重窗口；
• 抓取完成后逐批解析、处理资源并生成最终输出分块；
• ZIP 查看器一次只加载一个消息分块；
• 完成、失败或取消后清理原始暂存数据；
• 状态持续显示已写入消息数、批次数和最近活动。

4. 删除第二条历史查询路径

安全分页完成后不再执行会重新访问群历史的 repair_group_message_sequence。解析、资源处理和导出阶段不会再次读取群历史。

输出兼容性

普通 HTML/JSON/TXT/Excel 导出路径未修改。百万级流式 ZIP 需要完整解压后打开 index.html。

验证

自动测试覆盖：

• 本地数据库方法及查询参数；
• 禁止回退到危险原生历史接口；
• 20 → 50 → 100 → 200 的批次升速和上限；
• 响应结构、时间与关键词筛选；
• 磁盘暂存、清理、进度合并和资源路径改写；
• Rust exporter/server、插件测试、API smoke 与多平台构建由 CI 验证。

自动测试不能模拟提交者的 150 万条 QQ 本地数据库。CI 通过后仍需在原数据集上确认：已写入数量是否从 0 增长、Worker 是否保持登录、是否最终生成 ZIP。

[vercel]

@Tyr1onX is attempting to deploy a commit to the shuakami's projects Team on Vercel.

A member of the Team first needs to authorize it.