现象
v3.18.7 发版时 bun-binaries-musl (ubuntu-24.04-arm, bun-linux-arm64-musl) 腿的 smoke 失败：
smoke: ✅ capabilities / version(3.18.7) / selfcheck / self-spawn
smoke: ✅ dashboard — booted clean (0 restarts), embedded modules resolve
smoke: FAIL [http] dashboard port 19891 never served within 20000ms
(last error: fetch failed). The process is online but its HTTP listener never bound.
因为 binary-subpackages 与 release 都 needs: bun-binaries-musl，这一条腿挂掉会让整条发布链 skip（fail-closed 是对的，零污染），但发版就得人工重跑一次。
判据：这是时序问题，不是代码缺陷
- 同一个 commit 的 x64-musl 腿，同一条 http 检查，通过（8 项全绿）。同代码同检查，只有架构不同。
- 失败前一行是
dashboard — booted clean (0 restarts)，进程是活的，只是 socket 没在 20s 内 bind 上。
- 该腿近 6 次发版 5 次 success / 1 次 failure（含约 40 分钟前同代码的 canary 成功）。
- arm64 腿整体更慢：本次 arm64-musl 1m50s vs x64-musl 1m29s。
根因推测
scripts/smoke-bun-binary.mjs:65
const DASHBOARD_ONLINE_TIMEOUT_MS = 30_000;
const DASHBOARD_HTTP_TIMEOUT_MS = 20_000; // 与架构无关的固定值
DASHBOARD_HTTP_TIMEOUT_MS 是在 online 等待之后另起的预算，且是扁平常量、不区分架构。arm64 runner 上跑 musl 容器、加载 170MB 单文件二进制并绑 HTTP 端口，比 x64 慢得多，20s 有时不够。
建议
三种都可以，倾向前两种：
- 按架构放宽：
process.arch === 'arm64'（或读 env）时用 40s。只在慢的那一侧付代价。
- 统一调宽到 40s。判据不会因此变弱——它等的是"socket 到底有没有 bind"，等更久只会让真缺陷（永远不 bind）依然失败，而不会放过任何东西。超时只影响"多久放弃"，不影响"通过条件"。
- 允许 CI 用 env 覆盖，发版腿设更长。
不建议做的：把这条检查改成可跳过或降级为 warning——它是唯一能证明嵌入的 native 真的被 dlopen 且服务起得来的判据，musl/glibc 两条链都靠它兜底。
影响
不影响已发布产物，只影响发版流程的稳定性：每次发版都有一定概率被这条卡住并需要人工重跑（重跑还要求 run 不在进行中，若 desktop 停在 macos-signing 审批闸上就得先处理那个闸）。
现象
v3.18.7发版时bun-binaries-musl (ubuntu-24.04-arm, bun-linux-arm64-musl)腿的 smoke 失败：因为
binary-subpackages与release都needs: bun-binaries-musl，这一条腿挂掉会让整条发布链 skip（fail-closed 是对的，零污染），但发版就得人工重跑一次。判据：这是时序问题，不是代码缺陷
dashboard — booted clean (0 restarts)，进程是活的，只是 socket 没在 20s 内 bind 上。根因推测
scripts/smoke-bun-binary.mjs:65DASHBOARD_HTTP_TIMEOUT_MS是在 online 等待之后另起的预算，且是扁平常量、不区分架构。arm64 runner 上跑 musl 容器、加载 170MB 单文件二进制并绑 HTTP 端口，比 x64 慢得多，20s 有时不够。建议
三种都可以，倾向前两种：
process.arch === 'arm64'（或读 env）时用 40s。只在慢的那一侧付代价。不建议做的：把这条检查改成可跳过或降级为 warning——它是唯一能证明嵌入的 native 真的被 dlopen 且服务起得来的判据，musl/glibc 两条链都靠它兜底。
影响
不影响已发布产物，只影响发版流程的稳定性：每次发版都有一定概率被这条卡住并需要人工重跑（重跑还要求 run 不在进行中，若
desktop停在macos-signing审批闸上就得先处理那个闸）。