dsh-workbuddy-connect-next 0.14.0

改名 dsh-workbuddy-connect-next，对齐 DSH 0.2.1-rc.2，并做五项性能改造。

改名

包名从 dsh-workbuddy-connect-functy 改为 dsh-workbuddy-connect-next。连带改的四处身份（漏任一处都是「装完才炸」）：

身份	旧	新
npm 包名 / 浏览器模块 id	dsh-workbuddy-connect-functy	dsh-workbuddy-connect-next
profile 里的 entry id	llm-workbuddy-functy	llm-workbuddy-next
HTTP 路由前缀	/plugins/dsh-workbuddy-connect-functy/*	/plugins/dsh-workbuddy-connect-next/*
locale 命名空间	settings.workbuddy.functy / panel.workbuddy.functy	settings.workbuddy.next / panel.workbuddy.next

浏览器模块 id 由 package.json 的 name 派生（tsdown.config.ts），所以这一处不会再漂。

对齐最新 DSH

• peer range 从 ^0.2.1-rc.1 收紧到 ^0.2.1-rc.2：当前 @deepseek-ai/dsh-* 全部包在 npm 上的最新线就是 0.2.1-rc.2，而 0.2.1-rc.1 早于本项目的编译基线。包管理器会在装错的宿主上直接拒装。
• pi-ai 守卫从「版本必须等于 1.1.0」放宽为「代际必须是 1.x」（src/pi-ai-guard.ts）。同一代际内部的补丁差异（1.1.5、1.4.0）与宿主的消息结构一致，原来的守卫会对它们误报，把操作者训练成忽略这条警告；0.8x 那一代仍然会被点名。
• 宿主矩阵同步到 ^0.2.1-rc.2（src/supported-hosts.ts），peer range 由表派生，测试同步。
• 明确记录了一条给使用者的事实：上游 npm 包 dsh-workbuddy-connect@0.7.4 把 pi-ai 钉在 0.87.1（0.2.0-rc.2 那一代），在 0.2.1-rc.2 上属于跨代际，表现是选中模型后一发消息就报 PI_AI_ERROR（本机此前装的正是这一版）。上游 0.7.8 已把 pi-ai 换成 1.3.0、本身可用；本包在它之上多的是界面、多账号与额度。

性能

1. 请求体只解析一次（src/upstream.ts）。此前一份 chat body 要被 JSON 解析并重新编码三遍：shim 先改写一次，区域预处理再改写一次，reasoning_effort 剥离又是一次。现在共享规则与区域规则在同一个对象上一次做完，只 parse 一次、serialize 一次。带图的请求体是 MB 级，重编码的开销正落在用户真正等待的那条路径上。 顺带把「线上格式」的所有权从 shim 收到 upstream 客户端 —— 只有它知道最终打的是哪个区域。
2. 账号池不再每请求写盘（src/account-pool.ts）。一次成功的对话会对用到的账号调用 clearCooldown，而健康账号上这是空操作 —— 旧实现仍然把整个池（含全部 token）原子重写一遍，等于每个请求一次同步写盘。现在只在行内容真的变化时才写。
3. 状态文档复用同一份额度缓存（src/web-status.ts / src/account-service.ts）。轮询此前会为「主账号余额」单独再打一次计费接口，而这份数据在同一批账号额度里已经有了。现在主账号的余额取自同一份缓存，每轮轮询少一次上游计费请求（两个变体各 60 秒一轮）。
4. 面板轮询感知页面可见性并在失败后退避（src/client/panel-store.ts）。后台标签页里每秒两次状态请求纯属浪费，现在页面不可见时完全停轮询，重新可见时立刻补一次；连续失败 3 次后把间隔从 60 秒退到 5 分钟，路由恢复后立即回到正常节奏。
5. 启动时先用本地账号池认领身份（src/index.ts 的 syncVariant）。桌面端认证文件是加密的，读取它要拉起 WorkBuddy 自己的 Electron 二进制来取密钥 —— 这是秒级的等待，而在这段时间里模型分组是隐藏的（没有账号就必须不暴露任何模型），于是「配置里直接指定 WorkBuddy 模型」的宿主在启动瞬间会拿到 UNKNOWN_MODEL。现在先用本地明文的账号池认领身份（毫秒级），桌面端的读取照旧进行、只是退居为对账。实测：headless 首轮从 UNKNOWN_MODEL 变成正常出答案。

新增测试：tests/account-pool-persistence.spec.ts（用 inode 判定是否真的落盘）、tests/upstream.spec.ts 里的「一次成型」线格式验收。

本机环境的两个必要条件（不属于代码改动，但决定能不能用）

• 企业代理的根证书要能被 Node 信任。本机流量经过本地 mitmproxy（HTTPS_PROXY=127.0.0.1:8888），Node 内置的 CA 集合不含它的根，于是插件向上游发请求会报
  unable to verify the first certificate。NODE_OPTIONS=--use-system-ca 在 DSH 宿主里无效（Electron 在被别的 App 调用时会屏蔽 Node 环境变量），可用的是 NODE_EXTRA_CA_CERTS：
  根证书已导出到 ~/.dsh/trust/mitmproxy-ca.pem，并用 launchctl setenv NODE_EXTRA_CA_CERTS … 让 GUI 启动的桌面 App 也继承它。
  症状是状态文档里 catalog.source 停在 saved、creditsError 写着 fetch failed —— 看起来像插件坏了，其实是证书链。
• node 版本要用 22.x（fnm 的 v22.23.2）。DSH runtime 自带的 node 24 加载 rolldown 原生绑定会被 macOS 的 Team ID 校验拒绝，vitest 起不来。

验证

typecheck（两把 tsconfig）、test（67 文件 / 901 用例）、build、test:engine 全绿。

实测（本机 DSH Desktop 0.2.1-rc.2 + WorkBuddy 桌面端已登录）：插件在桌面与 web 两个 profile 都加载成功，状态路由 signed-in，模型目录 live 20 个，额度 1289/1300 实拉；headless 一次真实对话经 DSH → 插件 → pi-ai → 回环 shim → copilot.tencent.com 走通并正常出答案。