fix(consultation): count visible text only for session quota (BUG-732)

Replace append_consultation_question so the 200,000 quota sums only user-visible text, and add a 1,000,000-byte whole-JSON physical cap. Both still return session_full. Advisory lock, request_id idempotency, and the 200-message cap are unchanged.

docs/BUG_HISTORY.md

@@ -11380,3 +11380,19 @@
 - 相关记录：BUG-464、BUG-555
 - 复发自：无
 - 修复版本：待发布
+
+## BUG-732 | 对话额度把思考文本算进去，十几轮就「已写满」
+
+- 状态：resolved
+- 首次发现：2026-09-15
+- 最近更新：2026-09-16
+- 影响面：`append_consultation_question`、`POST /api/consult` 的 `session_full`、咨询会话详情 `GET /api/sessions/[id]`
+- 用户现象：普通咨询问大约十几轮就提示「这段对话已写满，开个新对话继续吧」。200 条消息那档永远碰不到。
+- 触发条件：继续往同一段咨询会话里发问；助手消息带有 `thinkingText` / `thinkingSections`。
+- 根因：BUG-464 立下的 200,000 字符上限身兼二职却两职都没做好。求和把用户读不到的 `thinkingText`、`thinkingSections` 算进去，却不算同样入库的 `techniqueTruth` / `workflowReceipt` / `agentExecutionReceipt`。这不是回归，是那条上限从一开始就混用了「对话有多长」和「这一行有多大」。
+- 修复：新迁移 `CREATE OR REPLACE` 该函数。对话额度仍是 200,000，只累加 `elem->>'text'`。另加物理上限 `sum(length(elem::text))`，算式 50 轮 ×（正文约 4,000 + 思考 4,000 + 分节 3,000 + 三个 receipt 约 3,000）≈ 700,000，取 1,000,000。两档都返回既有 `session_full`。签名、返回列、error_code、advisory lock、`request_id` 幂等、200 条上限、单条 16,000 字校验均未改。
+- 验证：`frontend/tests/consultation-session-capacity.test.ts` 锁定额度求和不含 `thinkingText` / `thinkingSections`、物理上限算式、签名与 `session_full`。`frontend/tests/database-consultation-session-capacity.test.ts` 用真实 Postgres 覆盖思考不占额度、短正文+大 receipt 撞物理上限、额度边界不先撞物理上限；本机无 Docker，该文件 skip，不得写成通过。既有幂等 / 满员用例未改。
+- 防复发：会话上限必须分成两条各司其职的口径：面向用户的对话额度只数用户读得到的正文；面向存储的物理上限必须把整条消息 JSON 算全。新增会存进 `messages` 的字段时，必须明确它进哪一条，不得默认落进对话额度。
+- 相关记录：BUG-464
+- 复发自：无
+- 修复版本：待发布