[asr][windows] 拖动渠道后重启恢复旧提供商，可能误启用 Foundry

[leolulu]

我遇到的问题

我在 Windows 上发现，ASR 渠道的排序会在重启后退回去：把千问流式拖到第一位，完全退出再打开，火山引擎又回到了第一位。

更早的一次故障里，OpenLess 还意外切到了 Foundry 本地 Whisper，开始准备 Windows App Runtime 和本地模型。下面的步骤可以复现排序回退。最初切到 Foundry 时，我没有保存凭据库里每张渠道卡片的状态。

环境

• Windows 10 专业版，10.0.19045。
• OpenLess 2.0.0-Beta.3+build.20260926，对应发布标签 v2.0.0-Beta.3-tauri。
• 豆包／火山引擎（volcengine）和千问流式（Bailian）两个 ASR 渠道都已配置并启用。实验中我没有关闭渠道，也没有主动选择本地模型。

怎么复现

1. 我先完全退出 OpenLess，确认 %APPDATA%\OpenLess\preferences.json 里的 activeAsrProvider 是 volcengine，再启动应用。此时火山引擎排在已启用 ASR 渠道的第一位。
2. 在「语音识别」页面，把「千问-流式」拖到第一位。页面马上显示新的顺序。
3. 此时查看同一配置文件，activeAsrProvider 仍然是 volcengine。
4. 从托盘完全退出 OpenLess，再重新打开。火山引擎又回到了第一位。

期望：重启后千问流式仍排在第一位，并继续作为当前 ASR。

实际：排序回退已经在我的电脑上复现。这次实验没有另外记录重启后的录音结果。

为什么我觉得这里有问题

之前合并的 #918「LLM/ASR 供应商改成渠道卡片」写得很明确：“排序即优先级，列表里第一个启用的就是当前生效的渠道。”它也提到，偏好文件和凭据库里的当前渠道在历史上可能不同步。现在拖动后的顺序已经保存，重启时却又按旧偏好改回去，我觉得这和 #918 的排序规则对不上。

我查了这个版本的代码，过程看起来是这样的：

1. 拖动时，前端调用 reorderChannels；Core 会调整顺序和当前渠道，再把渠道信息保存。这一步没有修改 preferences.json 里的 activeAsrProvider。
2. 启动时，程序又用这个旧偏好调用 sync_active_asr_provider_to_vault；选中渠道时，它会被移到最前面。

所以我怀疑，重启时旧偏好把已经保存的排序覆盖了。#1016也提到过偏好值和运行时渠道不一致；我在这里报告的是重启后排序回退。

最初那次 Foundry 问题

那次我查看配置文件时，activeAsrProvider 还是 foundry-local-whisper；现在我已经把它改成了 volcengine。Windows 的默认偏好值也是 foundry-local-whisper。

本机日志里有这些 UTC 时间点：

• 2026-09-28T04:33:27Z：火山引擎连接成功。
• 04:38:47Z：OpenLess 再次启动。
• 04:40:55Z：开始录音；随后 04:41:02Z 出现 [foundry-asr] Windows App Runtime probe (before install)，04:41:31Z 记录 Runtime 安装程序退出码 0x00000000。

日志能确认程序进入了 Foundry Runtime 准备流程。我当时也看到了本地模型准备／下载，但现存日志无法确定 Whisper 下载的具体时间；那时凭据库的完整渠道快照也没有保存。

我希望修复后的行为

把一个已启用的渠道拖到第一位后，完全退出再打开，它仍在第一位，实际 ASR 也继续用它。旧配置的兼容处理和 Windows 首次安装时的默认渠道可以保留现有做法；activeAsrProvider 字段和凭据结构也不需要因为这个问题而重做。同一家厂商有多张卡片时，渠道 ID 与 providerType 的区别也应保留。

对应的最小修复 PR：#1123。

[HKLHaoBin]

已通过 #1126 合入 beta（对应 PR 因集合发布被 closed 而非 merge，未能自动关闭本 issue）。