v1.7.3 — 模型不会因为一次网络抖动就消失

开机那一秒网络还没起来，插件就把模型列表「降级」了，然后一整天都不再试第二次。

你会看到：某次重启后，国内版的模型从 16 个变成 10 个，deepseek-v4.1-flash 之类凭空消失（国际版没事）。更麻烦的是你之前勾选过那个模型，于是依赖这个 provider 的东西开始报错（has no configured model "deepseek-v4.1-flash"），会话被悄悄切到国际版的同名模型上，而你根本不知道为什么。

界面没有任何提示 —— 只有日志里一条不起眼的 [W]。点卡片上的「重新检测账号」？没用。唯一的恢复方式是重启 DSH。

为什么：启动时去拉模型列表，那一次失败了（日志显示同一秒里有好几个独立组件都报 fetch failed，而 0.7 秒后国际版就成功了 —— 典型的开机网络还没就绪）。失败之后：

1. 不重试，一次就放弃；
2. 静默回退到插件内置的那张静态表 —— 那张表里没有 deepseek-v4.1-flash，于是「拉取失败」在你眼里就是「模型被删了」；
3. 「重新检测账号」这个按钮只重新扫描账号，压根不碰模型列表。名字起得太容易让人误会，你会以为它能修好，实际什么都不做。

怎么修的：

• 拉取失败自动重试（1 秒 / 3 秒 / 8 秒，最多 3 次）。开机抖动基本一次就能救回来。重试会写日志并标明第几次，所以「列表为什么慢」是可查的。一个 region 的重试不影响另一个 —— 两个网关是独立主机，没理由同归于尽；
• 新增「重新获取模型」按钮，并把它和「重新检测账号」分清楚：前者只管模型，后者只管账号，而且后者现在也会顺带刷新模型（因为大家都会去点它）；
• 卡片会明说：当前列表是「内置列表（离线）」时，模型区标题旁挂一个橙色标记，告诉你在看的是兜底表而不是完整清单，旁边就是重试按钮；
• 兜底表按真实上游数据重建。这是顺手挖出来的一个更严重的问题：旧表几乎全部过时 —— hy3 的窗口写着 32K（实际 192K）、kimi-k3 这个 id 上游早就不用了（实际是 kimi-k3-1），而 deepseek-v4.1-flash、kimi-k2.6/2.7/2.8、glm-5v-turbo、hy3-x 全都不在表里。我是直接拉了国内版的真实接口逐条核对后重写的，包含窗口大小和倍率。过时的兜底表比短表更糟 —— 它看起来权威，实际是错的。

一个差点修反的地方（顺手修了，免得白干）

改完重试我差点以为完事，结果发现：「刷新失败」会把一个本来正常的列表也打回兜底状态。也就是说，如果当前用的是实时列表、只是这次刷新没成功，卡片反而会显示「离线」。这是修反了 —— 所以现在刷新失败保留现有列表，只有真的没有实时数据时才标记为兜底。

明确没做的

• 不做定时自动重拉。开机失败已有重试兜底，而正常运行时定期轮询模型接口只会增加无谓的上游请求；真要更新，点按钮即可。
• 不做「缓存上次成功的列表到磁盘」。这能彻底消灭回退问题，但会把模型清单持久化，涉及与 settings 文档的版本兼容；本轮先修「抖动即降级」这个主因，不夹带更大的改动。

验证

• 类型检查全绿，测试 274 项全绿（原 262 + 新增 13，另删掉 1 项一次性探针）。
• 新增 tests/catalog-resilience.test.ts 覆盖：首次失败第二次成功的恢复、用尽重试后抛错、被调用方主动取消的请求不重试（否则会在被要求停止后继续干活）、重试写日志、兜底表含关键模型且无重复 id、窗口值均有效。
• 反向验证：把重试去掉 → 3 项变红；把「刷新失败降级」的错误改法放回去 → 1 项变红。确认测试真的能抓住这两个缺陷。
• 拉取国内版真实接口核对兜底表：共 16 个模型，已全部按实测数据录入。