[UX/FR] settings.yaml 校验失败时前端静默丢弃提供商且无任何提示

[pinewhite]

settings.yaml 校验失败时前端静默忽略该命名空间，导致已配置的提供方完全隐形且无任何报错提示。

问题场景

当手动或通过插件编辑 ~/.dsh/settings.yaml 存在轻微格式瑕疵时（例如在 llm-pi-ai.providers.<name>.models 列表中多加了一个破折号导致项缺失必填的 id），DSH 启动时会触发 Schemastery 的 ValidationError: $.providers.<name>.models[1].id missing required value。

实际表现

触发 ValidationError 后，整个 llm-pi-ai 命名空间被跳过，Web UI 前端没有任何报错弹窗或警告横幅，模型设置列表里仅剩官方内置的 DeepSeek，用户此前配置的所有自定义提供方直接在界面上消失。这极易被误判为“API Key / 凭据丢失”或“配置被清空”，且由于界面毫无报错提示，排查难度极大。

改进建议

1. 警告横幅（Warning Banner）：当 settings.yaml 解析或 schema 校验出现错误时，在 Web UI（如“设置 -> 模型”页面顶部或全局状态栏）展示可见的警告横幅。
2. 错误详情定位：在横幅或弹窗中指出具体的校验失败字段路径（如 $.providers.go.models[1].id），并引导用户检查并修正配置文件，避免静默丢弃。

[argszero]

同一族缺口的第二个独立报告（前端侧），值得把家族上下文摆出来——#5761 报告的是后端同一症状：llm 命名空间里多个字段是 required 且无 .default()（如 llm-deepseek 的 baseURL/thinking/reasoningEffort），配置缺失时整个 section 静默坍缩成 void 0，再逐字段回退到内置默认值。当时核出两个失效面：schema 解析失败 = 全静默（无日志）、越界值 = 有日志（走 apply() 的 last-good 路径）。你这条是第三个面，也是用户最痛的一个：ValidationError 触发后整个命名空间跳过，Web UI 无任何提示，已配置的 provider 集体隐形——用户会先怀疑凭据丢失或配置被清空（你文里说的），排查方向完全错误。

三点补充，按修复层排序：

1. 根修在配置/设置层，不在前端横幅。静默发生在加载/installSection 处：ValidationError 被当作「该命名空间无效」整体丢弃。正确行为 = 保留 last-good 并在加载处发出可见错误（含具体字段路径 $.providers.<name>.models[1].id），前端横幅只是把同一错误展示出来。headless 用户同样需要它——所以日志/事件通道和 UI 要一起补，不能只做横幅。
2. 字段路径是关键信息。Schemastery 的 ValidationError 自带完整路径；把路径透传到横幅/日志，用户 10 秒能修好；只报「llm-pi-ai 配置无效」又会变成新一轮误判。你的建议 2（错误详情定位）是正确的最小修复。
3. 这与 [bug] llm-deepseek Config namespace silently reverts to DEFAULT_MODELS (and every other field default) when one required sibling field (thinking/reasoningEffort) is missing #5761 同根：schema-parse 失败静默是设计缺陷而非有意为之——上游对「越界值」有 last-good 保护（有日志），唯独「解析失败」这条路径没有任何保护或提示。两条路径应当行为一致：要么都有可见错误，要么都保留 last-good。

家族里 #5761（后端静默回退）与你这条（前端静默丢弃）合起来 = 一个完整证据：配置平面的失败不可见性已经让至少两类用户（CLI 配置者 + UI 配置者）各踩一次。修复放在 installSection/settings 层一次覆盖两端。