[asr] 增加 LLM 前置混淆词纠错层

[appergb]

现象

当前流水线是 ASR raw transcript 直接进入 polish：coordinator.rs:616-617 读取热词后调用 polish_or_passthrough。当 ASR 产出明显不符合语境的词时，后续 LLM polish 只能被动整理，且现有 prompt 又偏向保留中英混输和专有名词，导致错误词可能被原样输出。

典型例子：开发语境下用户说“提交 issue / issues”，ASR 或后处理可能输出为 iOS，最终文本也会保留错误。

影响

• 语音输入结果出现“八竿子打不着”的词，用户需要手工回改。
• 只靠 prompt 很难稳定覆盖所有同音、近音、跨语言缩写混淆。
• GitHub、CI、PR、issue、tag、release、workflow 等开发词汇属于高频场景，错误会直接污染后续提交、issue 和 AI prompt。

建议接受标准

• 在 ASR 结果进入 polish 前，增加一个可维护的轻量纠错层或候选词归一化层。
• 纠错层支持上下文条件，不做全局机械替换。例如开发语境中 iOS 可纠正为 issue，但 Apple 平台语境必须保留 iOS。
• 纠错规则应可测试、可扩展，并能接入用户词汇本或内置高频混淆词表。
• 增加覆盖 issue/iOS、PR、CI、tag、release 等开发词汇的回归测试。
• 纠错失败或不确定时应保守保留原文，避免创造用户没说过的信息。

TODO / 不确定项

• 需要确定纠错层是纯本地规则、LLM 小提示、还是规则 + LLM 双阶段。
• 需要收集更多真实 ASR 错词样本，避免只为单个案例硬编码。

[H-Chris233]

也许我们可以直接把这层做进LLM输入?
这样有助于LLM通过上下文语境来理解当前问题并分析

[H-Chris233]

我查了 issue #89 和当前代码，结果是：

• ✅ 有部分替代能力
  1. ASR 热词注入：asr/volcengine.rs 会把词表注入 ASR context.hotwords（识别前偏置）。
  2. LLM prompt 热词优先：polish.rs 的 compose_system_prompt 会提示“同音/近形优先按热词写法输出”。
  3. 上下文前提：working_languages + front_app 作为 LLM 前提（不是显式纠错层）。
• ❌ 但 [asr] 增加 LLM 前置混淆词纠错层 #89 核心要求仍未落地
  1. 没有“ASR raw -> polish 前”的独立纠错层（coordinator.rs 仍是 raw 直接进 polish_or_passthrough/translate_or_passthrough）。
  2. 没有看到 issue/iOS、PR、CI、tag、release 的规则化纠错模块。
  3. 没有针对这些混淆词的专门回归测试。

所以从验收口径看，#89 仍应判定为 未完成（部分覆盖）。