v1.7.3 — 设置卡片不再空白，批量 405 不再把你引向错误的修复

🩹 v1.7.3 — 设置卡片不再空白，批量 405 不再把你引向错误的修复

这一版全是客户端健壮性修复，移植自同族 dsh-connect-workbuddy（MIT，同作者）——qoder 的卡片本就复刻自 workbuddy，上游修过的坑不该在下游重踩。三处都表现为「界面安静地坏了」：没有红横幅、控制台也干净，只是卡片存不了设置、或提示你做一件根本无效的事。宿主侧一行没改。

---

一、设置卡片整页空白，且没有任何报错

症状：插件列出来是 running，描述和组件行都在，但配置卡片正文一片空白；控制台干净，没有任何错误。

成因：宿主的 settings 镜像由异步 remote.settings.describe() 填充，插件 apply 那一刻它通常还是空的。旧代码把这份「空」当成「我声明的命名空间名一定对」，绑了一个 forms.get(声明名) 之后再也不回看；而宿主按命名空间精确匹配，于是这个猜错的 form 永远停在 unavailable——用户看得见卡片，却存不了任何设置。

修法：改成订阅宿主的 whileServed，等命名空间真正到货才绑定，并重建全部槽位注册（先 dispose 再注册——渲染器按 entry 身份缓存 inject 结果，旧注册留着就一直发旧 props）。即使边缘永不触发（宿主没挂可配置项、settings 面答得晚），也无条件先注册一次：卡片没有 form 也能按只读渲染，那总比不注册强。宿主那条线没有 whileServed 时回退成单次绑定。

顺带修掉两个移植时走样的地方：两个 composer 读数槽漏了 return，disposer 从不被追踪（fiber 拆除时泄漏、重绑时撞「already has an entry」被静默吞掉，读数永远停在第一代闭包）；命名空间候选表只监视一种拼写，宿主以 include: 前缀挂载时边缘永不触发、兜底成了死代码。

二、批量接口 405 的误导文案

症状：账号池的签到 / 测试 / 移除返回 405 时，卡片说「请确认插件是最新版本后重试」——可插件已经是最新的。

成因：那种 405 根本不是本插件拒绝该方法，而是宿主进程还在跑更旧的构建、那条路由从未注册，宿主的 HTTP 层在为一个不存在的路由作答。旧文案把用户引向「升级插件」这条走不通的路，真正该做的是重启 DSH。

修法：每条池路由的 handler 都以 JSON 作答（含自身的 405），所以「405 且响应体不可解析」就是宿主路由缺失的指纹。命中时改提示重启应用，并明确否定「重装或升级插件」。以 JSON 作答的 405 仍是「方法不对」，别的状态没有 body 也照旧措辞。

三、这一版的测试

两条改动此前零覆盖，这次补了 17 条。其中 9 条直接 import 真实的 apply()——上游那边导入真实入口会拉进浏览器专属的宿主包，只能测手抄的镜像副本（会随产品漂移而静默失效）；qoder 侧实测可以直接 import，所以断言的是产品代码本身。

六个变异逐个跑过验证测试真抓得住：加回早期猜测绑定、去掉两个 return、候选表缩回单一拼写、重绑顺序倒置、去掉 405 限定、去掉 bodyUnreadable 判据——每个都至少一条用例变红。

---

完整逐条记录见 CHANGELOG.md。升级后请重启一次 DSH（宿主进程需要重新注册路由）。