fix(consult): stop the consult-gate VedAstro wait and record step timing

Consult turns reuse a same-day official snapshot inside the rectification gate, or record deferred_in_consultation instead of starting another 4-second snapshot. Classification, step 0, step 1, and the time to the first answer character go into the existing usage metadata and a new admin usage column.

BUG-1231, BUG-1232

docs/BUG_HISTORY.md

@@ -16627,3 +16627,33 @@
 - 相关记录：BUG-995（前端测试要同时看 cancelled 和退出码）。
 - 复发自：无
 - 修复版本：待发布
+
+## BUG-1231 | 咨询链校正闸同步白等 VedAstro 官方快照，失败还不缓存
+
+- 状态：resolved（分支 `codex/consult-latency-quickwins-20261005`）
+- 首次发现 / 最近更新：2026-10-04 / 2026-10-05
+- 来源：10-04 只读审计。任务书 `docs/tasks/TASK-consult-latency-quickwins-20261005.md`。写任务书时，在装了 vedastro SDK 的沙箱网络下按产品路径测得每个领域约 4.6 秒，第二轮仍是 4.6 秒。这组秒数不是本轮在这台机器上重测的。
+- 影响面：普通对话引擎里校正闸附带的 `rectification.vedastro_gateway`。顶层前台 VedAstro（BUG-301）不改。直接调用 `/api/rectification_gate`、请求里没有咨询标记时，仍走原来的官方快照。
+- 现象：同一份咨询响应里，顶层 `vedastro_gateway` 可以已经是 `official_verified`（BUG-727 的当日缓存），校正闸里的 `official_closure_reason` 仍是 `official_raw_response_missing`。校正闸每次再起一个最多 4 秒的子进程。失败结果不进正缓存，同一天每一轮都再等。屏蔽外网时引擎每个领域约 0.75 秒，这 4 秒是额外等待。生产机器是不是也在等，本轮没能在 staging 上确认（进度记录 T0）。
+- 根因：咨询工作流把「外部证据可以后做」这个标记只传给顶层前台任务。校正闸仍调用原来的官方快照。出生时间进校正闸时被规范成浮点，和正缓存的键对不上，所以当天已经有的官方结果也复用不到。
+- 修复：只在校正闸、且请求带了这个标记时，改走咨询专用路径。先用原始请求里的出生数据、岁差、交点、UTC 日期查正缓存，命中已验证结果就复用；否则查当天的负缓存；都没有就记 `official_closure_reason = deferred_in_consultation`，不起子进程，也不标成已验证。负缓存单独存放，只认当天的 UTC 日期。没有这个标记的校正请求仍调用原来的 gateway。
+- 验证：`tests/test_vedastro_consultation_snapshot.py`。咨询路径不调用快照子进程，也不调用原来的 gateway。负缓存同日命中、次日失效，邮箱不进缓存。当天已验证快照优先于负缓存，整数小时和规范后的浮点小时靠原始请求对齐。没有标记的校正面，返回包与现场结果逐项相同。增长合同通过，没有新增类方法。本机没有 vedastro SDK，4.6 秒降到 1 秒以内没有重测。v5 打分文件没有改动，本轮没有重跑 77 例。
+- 防复发：上述测试。开关只放在校正闸里，不放进顶层 gateway，避免把 BUG-301 的前台核对也跳掉。
+- 相关记录：BUG-727（当日正缓存）、BUG-301（顶层前台照旧，本单不推翻）。
+- 复发自：无
+- 修复版本：待发布
+
+## BUG-1232 | 普通对话看不到第 0/1 步耗时和推理 token，分类耗时进不了用量
+
+- 状态：resolved（分支 `codex/consult-latency-quickwins-20261005`）
+- 首次发现 / 最近更新：2026-10-04 / 2026-10-05
+- 来源：10-04 只读审计。任务书同上。审计写答题步大约 1 万推理 token、大约 45 秒，但线上记录里没有逐步耗时和推理 token，后面的「限制推理强度」「精简说明」对不上数。这组数字不是本轮实测。
+- 影响面：`[agent-observability]` 日志，以及用量账本里已有的 JSON 字段。不改表，不加迁移。不改提示词和数据卡。
+- 现象：已有首字节、工具耗时、答案首输出、整轮耗时、总 token。没有第 0 步和第 1 步各自的耗时，也没有推理、输出、输入、缓存输入 token。分类耗时没有进用量记录。没有「第 1 步开始到第一个正文字」的时间。
+- 根因：流式过程没有按步骤记下供应商返回的 usage。用量记录和用量页都没有这些字段。
+- 修复：流式过程记下第 0 步和第 1 步的耗时和供应商 usage。供应商没返回的数写空，不估算。`answer.reasoning_ms` 从第 1 步开始计到第一个非空白正文字；第 0 步的旁白不计。分类耗时同时写入可观测事件和用量记录。步骤数字写入用量记录的 `modelSteps` 和 `answer.reasoning_ms`。用量页多一列「分段」。各领域工具耗时保持原字段。正文、提示词、出生资料、用户标识不写入这些字段。
+- 验证：`frontend/tests/consult-latency-timing-20261005.test.ts` 4 项通过。模拟步骤的日志和用量字段齐全，不含植入的正文。流式一轮把计时留在运行状态上，公开回执和响应正文里没有这些字段，也没有那段正文。`tsc --noEmit` 0 错。`npm run lint` 0 error，既有 warning 未动。用量页本轮没有登录打开。
+- 防复发：上述测试锁住对话路由、用量列表查询和页面列名。可观测结构是严格对象，多出来的正文字段进不了事件。
+- 相关记录：10-04 咨询耗时审计（任务书事故实证第 2 条）。
+- 复发自：无
+- 修复版本：待发布