[coord] recorder started (asr=volcengine, phase=Starting)
[coord] ASR connected; flushed 3520 deferred audio bytes
[asr] server JSON: {"audio_info":{"duration":10250},"result":{"text":"我是看到...","utterances":[...]}}
[style-pack] llm polish assembled provider=deepseek model=deepseek-flash mode=Structured
[llm] POST https://api.deepseek.com/v1/chat/completions provider=deepseek model=deepseek-flash
[llm] HTTP 200 body={...,"content":"我看到在工具..."}
现象
触发条件：ASR 提供商选用火山引擎，鉴权模式为「新版控制台 API Key」，填入 API Key 后。
当前表现：
概览页 ASR 卡片右上角显示灰色「未配置」徽标（同页 LLM 卡片正常显示绿色「已配置」）。但 ASR 实际工作完全正常。证据：
界面截图：ASR 卡片显示「火山引擎 bigasr / volcengine」+「未配置」；LLM 卡片显示「DeepSeek / deepseek」+「已配置」。
凭据保险库（
credentials.v1.chunk.0.com.openless.app，UTF-16LE JSON）中该 provider 的实际内容：注意
lastTest.ok = true，即连接测试已通过，却仍判定未配置。运行日志证明链路完全可用（火山识别 → DeepSeek 润色 → 文本插入）：
直接对端点做 WebSocket 握手，同一把 API Key 返回
101 Switching Protocols：而换用
volc.bigasr.sauc.duration则返回403 {"error":"[resource_id=...] requested resource not granted"}—— 可反证seedasr资源在该账号下确已开通。判定字段：后端下发给前端的结构里含
asrConfigured、llmConfigured、omniConfigured、volcengineConfigured、arkConfigured。该徽标应由asrConfigured/volcengineConfigured驱动。结合lastTest.ok=true仍显示未配置，判断为状态判定逻辑与运行时凭据读取逻辑不一致。一个可能的成因（未验证，供参考）：
volcengineConfigured的判定可能未按authMode分支，在api_key模式下仍去检查旧版控制台必填的APP ID/Access Token字段；而运行时凭据加载逻辑是按authMode正确分支的，因此出现「能用但报未配置」。另一处可疑点（同源但独立，若被认为应拆分请告知）：保险库中
active.asr指向的键名为foundry-local-whisper、active.llm指向ark，但两条记录的providerType分别是volcengine与deepseek—— 键名与实际类型不同步（应为在既有 provider 条目上直接更改类型所致）。LLM 那条同样是旧键名却显示「已配置」，故此项可能不是该徽标的成因，但一并报告以免遗漏。影响
lastTest的成功结果直接矛盾，会引导用户反复重新填写 API Key 或去改安全组/资源包，浪费排查时间。建议接受标准
authMode = "api_key"时，只要volcengineApiKey已填写且lastTest.ok = true，asrConfigured/volcengineConfigured即为true，概览页显示「已配置」。providerType保持同步（或在读取时以providerType为准，不依赖键名）。TODO / 不确定项
asrConfigured还是volcengineConfigured（前端资源为压缩嵌入，环境无 brotli 解压能力）。上述绑定关系为根据字段名推断。