[polish] 为 OpenAI 渠道增加低延迟（Fast mode）选项 #1165

现象

我通常每次语音输入约 10 秒，ASR 完成后，LLM 润色还需要等待约 2～4 秒，整段润色完成后才会写入目标输入框。这段等待会明显影响连续使用体验。

OpenLess 已通过 #1125 支持火山方舟的低延迟选项，但当前实现仅对 ark 渠道发送 service_tier，希望将这一能力扩展到 OpenAI 渠道。

OpenAI 官方的 Chat Completions 和 Responses API 均支持 Fast mode，启用方式是在请求体顶层增加：

{
  "service_tier": "fast"
}

它可以在保留现有模型和 reasoning 设置的情况下使用。官方文档

我用一段模拟中文语音转写进行了小规模对照：固定 gpt-6.1-sol、reasoning=low、相同输入与简短润色规则，交替请求顺序，共测试 6 组、12 次请求。

6 组均为 Fast 更快，配对节省时间的中位数约为 0.69 秒。所有响应实际档位均符合请求，每次都是 130 输入 tokens、29 输出 tokens，缓存命中和推理 tokens 均为 0。

这是单一模拟输入的小样本结果，不代表实际使用中一定能获得相同比例的提速；测试也不包含 ASR 和目标输入框写入耗时。

影响

使用 OpenAI 进行语音输入润色时，希望能够自行选择以更高的 API 费用换取较短的等待时间。

建议接受标准

• OpenAI 渠道增加可选的“低延迟推理（Fast mode）”设置，按渠道保存。
• 未启用时不额外发送 service_tier，保持现有行为；启用时发送 "service_tier": "fast"。
• Chat Completions 和 Responses 两种请求格式均支持该设置。
• 设置旁说明 Fast mode 会增加费用，并提供官方价格说明，由用户主动选择。
• 在现有诊断信息中记录请求档位与响应实际返回的 service_tier，便于确认是否生效；未返回时如实记录。

TODO / 不确定项

• 第三方 OpenAI-compatible 服务对该参数的支持和计费方式可能不同，不应自动向所有兼容接口添加该字段。
• 不同模型及服务区域的支持范围需按官方文档确认，不支持时应提供明确错误提示。

相关需求：支持火山方舟低延迟请求参数 #1125。