[perf] 润色默认拼接 5 分钟内全部历史轮且不限条数，拖慢首字延迟（影响全体用户）

[appergb]

现象

新版本（1.3.6 起）非 Raw 模式的转写「停说话 → 出首字」延迟明显增大（用户实测约 +1s 量级）。属于面向全体用户的性能回归。

根因（已读源码确认）

引入「对话上下文感知润色」后，每次非 Raw 润色都会把最近 N 分钟内的全部历史轮作为 user/assistant 消息前置进 LLM 请求：

• src-tauri/src/types.rs:828 default_polish_context_window_minutes() 默认 5 分钟（开箱即开）。
• src-tauri/src/coordinator/dictation.rs:2151-2161：当 polish_context_window_minutes > 0 时调用 history.recent_within_minutes(...) 拉历史。
• src-tauri/src/coordinator/dictation.rs:2508 eligible_polish_context_turns(...) 末尾直接 .collect()，对条数没有任何上限。

历史越长，前置消息越多 → 输入 token 越大 → 模型首 token 时间（TTFT）越长。在默认流式插入下，TTFT 恰好就是「光标出现第一个字」的时刻，于是表现为转写变慢。

次要叠加：recent_within_minutes（persistence.rs:1212→:1258）在 ASR 出文本与发起 LLM 之间，于 tokio worker 上做整文件同步 JSON 读取+反序列化，无缓存（不同于 CREDENTIALS_CACHE）。

影响

所有使用润色/结构化/翻译模式且 5 分钟内有历史的用户，每次转写都被拖慢。受众 = 全体活跃用户。

建议修法（单一职责，保留功能）

1. 给 eligible_polish_context_turns 增加条数上限（如取最近 1–2 轮），把上下文 token 控制在常数量级；可叠加一个 token 预算上限。
2. （可选）将历史读取移出热路径：HistoryStore 加内存缓存（仿 persistence.rs:83 的 CREDENTIALS_CACHE）或 spawn_blocking 包裹。

验证

• 新增单测：eligible_polish_context_turns 在多于上限的历史下只返回上限条数。
• 手测：5 分钟内堆积多条历史后，对比修复前后首字延迟。

来源：2026-06-16 全仓多 Agent 审计（延迟专项）。