chore(build): bun 统一升级到 1.4.2

[deepcoldy]

改了什么

把仓库里所有「当前使用的 bun 版本」从 1.4.1 提到 1.4.2，共 10 处可执行 pin：

载体	处数
package.json 的 packageManager	1
ci.yml / release.yml 的 setup-bun bun-version	6
两条 musl 腿的 npm i -g bun@（setup-bun 不支持 musl，只能走 npm）	2
scripts/build-linux-glibc-baseline.sh 的 npm install -g bun@	1

外加描述「当前 pin」的文档/注释：CLAUDE.md、CONTRIBUTING.md、src/utils/local-dev-update.ts。

为什么这么改

历史实测记录一律不动。 darwin 签名那几段（1.4.0 写坏签名、1.4.1 只修了 host arch）记的是历史事实，不是当前状态，改了就是伪造实测。

但有两处例外必须跟着走：build-bun-binary.mjs 和 gate 测试里那句「别把『我们已经在 1.4.1 了』读成『已经修好了』」——升完版读者眼前就是 1.4.2，警告指着一个没人会读到的版本号就失效了。所以这两处改成 1.4.2，并补上本次复测数据。

FIRST_GOOD_BUN 故意保持 1.4.1：它是「首个带 darwin 签名修复的版本」这个下限，不是 pin。跟着一起改会让断言退化成「pin == pin」的同义反复，就再也测不出「pin 是否带着修复」了。已在注释里写明这是有意为之。

影响面

改的是构建工具链版本，不是运行时代码，也不改任何依赖版本。受影响的是 CI 全部 job（build / bun-test / 三条 binary 腿 / release 全流程）与本地开发链路；不涉及具体 CLI 适配器、后端或会话类型。

bun.lock 未重新生成——1.4.2 完全接受现有 lockfileVersion 2（下面有实测）。

实测验证

均在本机 bun 1.4.2 下跑。worktree 内没有跑过 install，隔离验证都在 /tmp 副本里做。

锁文件兼容性（这项不过关的话 CI 每个 job 都会红）

干净副本 bun install --frozen-lockfile --dry-run   rc=0
  bun.lock sha256 前后一致 1a7ce58a…（未被要求改写）
真实 install（公共 registry，镜像主机名 0 次泄漏）  rc=0
  698 packages installed，node-pty 的 pty.node 正常编出（生命周期脚本跑到了）

升级前 → 升级后（同一批断言）

升级前：19 failed —— AssertionError: expected '1.4.2' to be '1.4.1'
升级后：3 files / 50 tests passed

（这批断言把 Bun.version 和 packageManager 对齐，所以本次改动是可观测的，不是空改。）

版本一致性闸 + 反变异

test/release-darwin-codesign-gate.test.ts   31/31 passed
三枪变异，每次只让一个载体漂回 1.4.1：
  ① workflow 的 bun-version  → 1 failed  expected ['1.4.2','1.4.1'] to equal ['1.4.2']
  ② musl 腿的 npm i -g bun@  → 1 failed  同上
  ③ glibc 脚本的 npm install → 1 failed  同上
三个载体各自都被真的守住，不是只守住了其中一个。

构建 / 运行时 / 编译态

bun run build            rc=0
bun test（直跑，非 vitest）  50 pass / 0 fail    bun test v1.4.2 (744846f84)
bun run test:bun:self-check  rc=0，且所有 bun spawn 都留在 home fence 内
bun run verify:binary    rc=0，编译态 8 项 smoke 全绿
  capabilities / version / selfcheck / self-spawn / dashboard / http / frontend / self-destruct guard

全量 unit（含红项归因）

vitest run --project unit   11 failed | 21899 passed (21923)

11 条红全部与本改动无关，逐条对照过：

• 其中 9 条：把同样 5 个文件在干净 master（同一台机、同一 bun、同样先 build 过）上跑，得到逐个用例完全相同的失败集合（diff 判定 IDENTICAL），是本机 bwrap 沙箱相关的既有失败。
• 另 2 条：满载下的时序抖动（stops reading slow partial stdin 3000ms 预算实测跑了 3066ms），单独跑即绿。
• 结构佐证：这 5 个红文件与 origin/master 逐字节相同，且都不读这个 pin。

⚠️ 归因过程中踩到一个坑，记下来避免复现：baseline 第一次跑出来是 7 red（比我这边少），差异其实来自 plugin-mcp-sandbox 的 skip 条件是 existsSync('dist/cli.js')——/tmp 里的 baseline 是 git archive 导出的，没有 dist/ 所以整个文件被跳过了。给 baseline 补跑 bun run build 之后两边才对得上。

⚠️ 一个必须留档的结论：1.4.2 仍然没修 darwin-x64 交叉编译的签名缺陷

仓库里原本就写着「别以为升级 bun 就能删掉重签步骤」。既然这次真的升了版，我把它重测了一遍，而不是照抄旧结论：从 linux 交叉编译一个两行 hello-world，解析 CodeDirectory 重算 page hash（不需要 macOS），并用 1.4.0 做对照确认这个判据能区分版本：

1.4.0 → darwin-arm64: INVALID (1/15483)        darwin-x64: INVALID (2/17124)
1.4.2 → darwin-arm64: VALID   (15075/15075)    darwin-x64: INVALID (2/16792，含 slot 0)

arm64 那格从 INVALID 变 VALID，说明判据确实在区分版本、不是恒定输出；x64 交叉编译那格和 1.4.1 时代记录的形态一模一样，依旧是坏的。

结论：build-bun-binary.mjs 里的 codesign --force --sign - 重签步骤仍然是承重的，谁都别因为「我们已经升到 1.4.2 了」把它删掉。这个结论已写进代码注释。

（旧注释里还提到 x64 有 ~25MB 落在签名范围外，我这两次构建都没复现出来（gap 均为 0）。我新增的文字只陈述自己直接测到的 page-hash 判定，没有沿用那个 gap 数字。）