feat(chat): 前端显示上下文真实token消耗，/usage命令结果与cli格式同步

[GoldenFish123321]

问题

• bridge 模式下，前端进度条和 /usage 命令都使用本地 tiktoken 估算 token，而非上游 API 返回的真实消耗。
• /usage 只输出一行简单结果，和 CLI 的详细格式差距很大

根因

hermes agent conversation_loop.py:4156-4183 的返回值已包含完整 token 数据：

result = {
    "input_tokens": ..., "output_tokens": ...,
    "cache_read_tokens": ..., "cache_write_tokens": ...,
    "reasoning_tokens": ..., "total_tokens": ...,
    "api_calls": ..., "model": ...,
    "estimated_cost_usd": ..., "cost_status": ...,
}

bridge 原样透传到 chunk.result，但 TypeScript 端此前只用本地 countTokens() 重新估算。

效果

做了什么

提取真实 API 数据：新增 extractBridgeUsage() 从 chunk.result 中提取上游 token 消耗，写入 BridgeUsageState。这个数据通过 run.completed / run.failed 事件发给前端，同时持久化到 sessions 表，页面刷新后也能恢复。

修正进度条：hermes agent 返回的 session_prompt_tokens 会在多轮 tool call 时重复累加共享上下文，进度条显示的值是实际占用的 N 倍。改用 last_prompt_tokens（单次调用的真实 prompt 消耗），进度条终于显示准确的上下文占用。

重写 /usage：输出格式完全对齐 TUI CLI，包含完整的字段列表、成本估算、上下文占用百分比、消息数和压缩次数。数据优先从 live bridge 读取，其次从 DB 恢复，最后回退到本地 tiktoken 估算。

防止数据污染：DB 回退时拿到的 session_* 是上一轮的累加值（可能几百万 token），不能直接写进进度条。通过 lastPromptTokens != null 守卫严格隔离两类数据：有 lastPromptTokens 的是 live 数据，可以放心用；没有的是 DB 回退数据，只用于 /usage 的静态展示，不会覆盖实时进度条。这个守卫覆盖了所有注入路径——run.completed、/usage handler、切换会话的 resume、WebSocket 重连的 resume。

清理了几个边缘问题：每轮 run 开始清空 bridgeUsage 防上一轮失败数据泄露、updateSession() 跳过 undefined 参数防 SQLite binding error、loadSessions() 刷新时保留内存中的 apiUsage、run.failed 也提取 API 真实数据、duration 在 started_at 缺失时显示 N/A 而非 Date.now() 假值。

涉及文件

文件	改了什么
types.ts	新增 BridgeUsageState 接口
handle-bridge-run.ts	extractBridgeUsage() 提取 token、updateSession() 持久化、每 run 清空 stale data
session-command.ts	/usage 重写：live → DB → tiktoken 三层 fallback，格式对齐 CLI
index.ts	resume payload 携带 bridgeUsage
schemas.ts	sessions 表加 last_prompt_tokens 列（自动迁移）
session-store.ts	updateSession() 跳过 undefined 参数
chat.ts (client)	apiUsage 字段、提取 applyApiUsage()、resume/reconnect 路径统一恢复
chat.ts (api)	ResumeSessionPayload 加 bridgeUsage 字段
ChatInput.vue	进度条优先读 apiUsage.lastPromptTokens

兼容性

• 无 bridge 数据时自动 fallback 到原有 tiktoken 估算
• 进度条 fallback 链：lastPromptTokens → inputTokens+cache → contextTokens → inputTokens+outputTokens

[GoldenFish123321]

修了一些东西

---

进度条修正

hermes agent 返回的 session_prompt_tokens 会在多轮 tool call 时重复累加共享上下文，进度条显示的值是实际占用的 N 倍。改成取 last_prompt_tokens（最后一次 API 调用的真实 prompt 消耗），进度条终于显示准确的上下文占用。/usage 的 Current context 行也做了同样的修正。

DB 也加了 last_prompt_tokens 列，页面刷新后不会退化成累加值。

数据源隔离

live bridge 数据和 DB 回退数据不能混用。DB 回退时拿到的 session_* 是上一轮的累加值（可能几百万 token），直接写进进度条就炸了。

所有 apiUsage 的注入点——run.completed、/usage handler、切换会话的 resume、WebSocket 重连的 resume——统一用 lastPromptTokens != null 做闸门：有就是 live 数据，放心更新；没有就不碰 apiUsage，让进度条走现有 fallback。

DB 变更

sessions 表加了一列 last_prompt_tokens（syncTable 自动迁移）。updateSession() 也修了一个 binding error：bridge 返回的 cost 字段可能是 undefined，直接塞给 SQLite prepared statement 会报错，现在循环里遇到 undefined 直接跳过。

恢复路径

所有恢复路径现在都能正确处理 apiUsage：

• 切换会话：switchSession 的 resume 回调从 bridgeUsage 重建
• WS 重连：applyReconnectResume 同上（之前漏了这个路径）
• 标签页恢复：只刷 messages，不碰 token（本来就没问题）
• loadSessions 刷新：保留旧 session 的 apiUsage 不丢

ResumeSessionPayload 接口同步加了 bridgeUsage 字段，之前一直靠 (data as any) 拿。

/usage 格式对齐

输出格式完全对齐 TUI CLI（cli.py:10206-10234），包括完整字段列表、成本估算、上下文占用百分比。细节上 Reasoning (subset)、cache 行、compression 只在有值时显示，unknown 定价时补一句提示。

边缘修复

• 每轮 run 开始清空 bridgeUsage 防上一轮失败数据泄露
• run.failed 现在也提取 API 真实数据（之前只用了本地估算）
• loadSessions() 刷新时保留 apiUsage（之前刷新后进度条跳变）
• duration 在 started_at 缺失时显示 N/A 而非 Date.now() 假值
• /usage 多行输出用 \x0a 替代 \n 防 JSON 二次转义

[GoldenFish123321]

相关issue

• 聊天上下文使用量只显示未缓存的 input_tokens，数值严重偏低 #838