审计并升级 pinned vendor 中的 undici / esbuild 漏洞

[kdnsna]

发现

在固定提交 75d7db9338e133080fef9914b92ceb5e3ebd0dfc 上执行 vendor npm audit，报告 1 个 high 和 1 个 low：

• undici（直接依赖，<=6.26.0）：包含 WebSocket fragment count DoS 等公告，最高 high。参考 GHSA-vxpw-j846-p89q、GHSA-p88m-4jfj-68fv、GHSA-35p6-xmwp-9g52、GHSA-g8m3-5g58-fq7m。
• esbuild（间接依赖，0.27.3–0.28.0）：Windows 开发服务器任意文件读取，low。参考 GHSA-g7r4-m6w7-qqqr。

约束

• 不直接运行 npm audit fix，因为 vendor 必须保持可审计的固定提交和构建产物哈希。
• 不跟随上游 main；只选择明确的新提交并独立审计 QR、HTTP、加密和主动发送边界。
• 不启用上游 Router、Codex 适配器或远程控制入口。

验收标准

• 确认每条公告对当前仅扫码登录、上下文绑定和主动发送用法的实际可达性。
• 选择包含安全修复的明确上游提交或形成最小、独立的补丁方案。
• 更新 submodule pin 与 vendor 产物 SHA-256 清单，并记录审计差异。
• 根项目 329 项、vendor 81 项、类型检查、构建和微信测试发送全部通过。
• high 风险解决或以可复核证据判定不可达之前，仓库保持 private。

[kdnsna]

2026-07-21 本地修复状态：已选择“移除完整 vendor，而非升级并继续携带远程控制仓库”的闭环方案；新增项目自有最小单向 WeChat transport、运行时依赖闭包说明、OpenVEX component_not_present 记录和 CI 禁止导入边界。当前本地生产依赖审计为 0 漏洞，63 个测试文件共 644 项测试全部通过。远端仓库已复核并恢复为 PRIVATE。此 Issue 暂不关闭，待本地差异完成审阅、提交、推送且远端 CI 通过后再关闭。

[kdnsna]

已通过移除 cli-in-wechat vendor 闭环解决。

生产依赖图中已不存在 undici。
运行时闭包、OpenVEX、CI 禁止回归检查和最终验证见：

• PR Close release P0 hardening gaps #7（已 squash merge 至 main：3734495）
• docs/security/runtime-closure.md
• security/openvex.json

当前策略是项目自有最小单向 transport，不再 pin 完整上游 vendor；因此原“升级 pinned vendor 中 undici/esbuild”验收路径不再适用。Issue 关闭。