fix(consult): drop traces, budget checkpoints, silent summary inherit

BUG-729: dropped history rounds leave an omission marker in the model-visible summary slot.
BUG-730: checkpoint threshold is 0.4 of historyBudgetChars (128k still 16,000).
BUG-731: session_full new chat copies owned context_summary on the server; clients send only continued_from_session_id.

docs/BUG_HISTORY.md

@@ -11332,3 +11332,51 @@
 - 相关记录：BUG-727
 - 复发自：无
 - 修复版本：待发布
+
+## BUG-729 | 咨询历史丢掉整轮时模型看不见任何痕迹
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`consultationHistoryWindow`、`consultationUserTurnContent`、`POST /api/consult`
+- 用户现象：历史超过模型预算后，追问「刚才你说的那个时间」时模型当成从没说过。单条超长会写「省略 N 字」，整轮被丢掉时什么都不留。
+- 触发条件：普通咨询多轮之后，尾巴字符数超过当前模型的历史预算，窗口从最旧整条丢弃。
+- 根因：`droppedCount` 算出来了，`route.ts` 只取 `.tail`。BUG-555 的防复发只写了「不得再按固定 12 条 × 头部截断静默砍结论」，整轮丢弃不在字面里，所以没拦住。
+- 修复：`droppedCount > 0` 时在摘要槽追加与 `omissionMarker` 同风格的说明。有摘要时写「更早的 N 轮问答已并入上面的会话摘要」；没有摘要时诚实写结论尚未并入。`droppedCount === 0` 不加这句话。
+- 验证：超预算历史的模型可见文本含丢弃说明且轮数等于 `droppedCount`；零丢弃不加这句话；源码合同断言 `route.ts` 读取 `historyWindow.droppedCount`。
+- 防复发：咨询历史任何形式的丢弃（截断单条、丢整轮）都必须在模型可见文本里留痕。
+- 相关记录：BUG-555
+- 复发自：BUG-555（防复发只覆盖头部截断）
+- 修复版本：待发布
+
+## BUG-730 | 写摘要的阈值写死 16,000，追不上按窗口算出的历史预算
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`historyBudgetChars`、`consultationHistoryCheckpointChars`、`shouldCheckpoint`、`checkpointSessionContextSummary`
+- 用户现象：后台上架中等上下文窗口的模型后，每轮静默丢掉最老的几轮问答，摘要却还没开始写。
+- 触发条件：模型 `context_window` 低于约 70,667（例如 64k / 32k）。历史预算已经小于写死的 16,000 字阈值。
+- 根因：`shouldCheckpoint` 用常量 16,000，`consultationHistoryWindow` 用 `historyBudgetChars()`。两个数各写各的，没有「阈值必须低于预算」的断言。
+- 修复：阈值改为预算的 0.4（默认 128k 窗口仍是 16,000）。运行时断言阈值 < 预算。检查点把会话模型的 `contextWindow` 传进去。
+- 验证：表驱动覆盖 200k / 128k / 64k / 32k / null，逐条 `checkpoint < budget`；128k 仍为 16,000。
+- 防复发：触发摘要的阈值必须由历史预算派生，并由一条断言钉死「阈值 < 预算」在所有合法上下文窗口下成立。
+- 相关记录：BUG-555
+- 复发自：BUG-555（检查点阈值与窗口预算未绑在一起）
+- 修复版本：待发布
+
+## BUG-731 | 对话写满后开新对话不继承服务端已有的会话摘要
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`chatSessionCreateSchema`、`POST /api/sessions`、`continueInNewChat`、`startNewChat`
+- 用户现象：这段对话已写满、点「开新对话」之后，模型对刚才的结论一无所知，用户被要求从零开始。
+- 触发条件：`append_consultation_question` 返回 `session_full`，客户端走「开新对话」。
+- 根因：新会话是空的。`context_summary` 不在列表 GET 列里，创建合同也不接收它。即便前端想带，也没有合法入口。
+- 修复：创建合同增加可选 `continued_from_session_id`（保持 `.strict()`，不加 `context_summary`）。服务端按当前用户读源会话摘要，读到才写入新行；读不到、不属于该用户、或为空都静默跳过，仍返回 201。写满出口把当前会话 id 带进创建请求。界面不加「接着上次聊」之类提示。
+- 验证：带来源 id 时新行摘要等于源会话；源会话属于别人时新行无摘要且 201；源码合同断言创建 schema 没有 `context_summary` 字段；写满后「开新对话」没有新增提示文案。
+- 防复发：会话满员后的「开新对话」出口必须由服务端继承 `context_summary`；摘要文本任何时候都不得由客户端提供。不得把 `messages` 加回列表 GET。
+- 相关记录：BUG-464、BUG-555
+- 复发自：无
+- 修复版本：待发布