[eric8810]

问题

network-macos 上 dial_conformance 的 bun::a_wrong_token_is_retried_as_rejected 和 bun::an_incompatible_access_point_stops_the_dialer 从今天起几乎每个 PR 都失败（#563、#578–#582），报 timed out (10s): rutis: refused: auth-rejected ( / incompatible (。

不是 rutis 的某次合并引起的：这个任务装的是最新的 Bun（bun-version: latest），Bun 1.4.4 在 2026-10-22 10:19Z 发布，失败都在这之后。本地 macOS 上，同一份代码用 Bun 1.4.3 全部通过，用 1.4.4 稳定复现；bun/rutis-bun 自己的 test/websocket.test.ts 在 1.4.4 上也有两个失败。

原因（Bun 1.4.4 的 ws 客户端两处行为变化）

1. 升级被拒后不再关闭连接。有 unexpected-response 监听时，1.4.4 照 npm ws 的做法把请求交给监听者处理：发出 unexpected-response、读完响应体，之后没有 close。我们的拨出只在 close 时报错，所以要等到 10 秒的握手时限才失败，刚好超过测试的 10 秒上限。最小复现：1.4.3 在 7 ms 时 close 1002，1.4.4 3 秒后仍没有 close。
2. 证书被拒的报告方式变了。1.4.3 是 close 1015；1.4.4 是带 Node 错误码的 error（UNABLE_TO_VERIFY_LEAF_SIGNATURE）加 close 1006，被归成了 retryable。

修复（bun/rutis-bun/src/websocket.ts）

• 升级被拒：读完响应体（或者响应出错、关闭）就自己结束连接并报错，跟 Node 运行时（node/rutis-runtime/src/channel/websocket.mjs）的做法一样。新旧 Bun 都只报一次。
• 证书被拒：错误码指向证书（CERT|SIGNATURE|ALTNAME|ISSUER，跟 Node 运行时用的规则相同）时归为 auth-rejected。1015 仍然认，旧版 Bun 继续可用。
• docs/design-bun-runtime-2026-10-09.md / .en.md 同步改了说明。

验证

• Bun 1.4.4：bun test（bun/rutis-bun）通过 129 个、失败 0 个（修复前分类测试超时、TLS 测试得到 retryable）；cargo test -p rutis-bridge --all-features --test dial_conformance bun:: 通过 8 个（修复前失败 2 个）。
• Bun 1.4.3：bun test 通过 129 个。
• CI 的 network-macos 和 runtimes-bun (latest) 用的就是 1.4.4，runtimes-bun (1.4.0) 覆盖旧版。

其他用到 ws 的地方

bun/rutis-bun 里只有 src/websocket.ts 的 open（拨出）用了 ws 客户端，只有它依赖 close 和 1015 的行为。监听用的是 Bun.serve，连上以后的关闭由 wrap 处理。用 Bun 1.4.4 跑了 rutis-bridge 的 bun_channel、bun_runtime、websocket_conformance、websocket_cross、dial_conformance，全部通过。Node 运行时用的是 Node 上的 npm ws，不受影响。