fix(plugins): compile bundles in a child process so a wedged Bun.build cannot hang the server or CI

[cuongtranba]

The failure this fixes

The v1.58.1 publish (run 35817749252) died with exit 137: the CI hang watchdog SIGKILLed bun test after 170 s of silence. The diagnostics it captured tell the story precisely:

• plugin_validate > accepts the hello fixture without installing it failed at its 60 s test timeout — the compile never finished
• the next compile-running test never printed at all
• bun sat idle in ep_poll with zero child processes — nothing external was stuck; the bundler wedged in-process

Root cause

buildPluginBundles ran Bun.build in-process with JS plugin callbacks (onResolve/onLoad for the host-module rewrite). On bun ≤ 1.3.x all Bun.build() calls serialize behind a single bundle thread, which can park inside the in-flight build's MiniEventLoop waiting on plugin work — fixed upstream in oven-sh/bun#35060 and oven-sh/bun#42680, neither in the pinned bun 1.3.11. Once one build parks, every later compile queues behind it forever. In production the identical wedge would hang a real install / validate / reload RPC with no way out.

Fix — process isolation, the pattern the plugin system already uses

buildPluginBundles now spawns plugin-build-child.adapter.ts (same process.execPath + script-path shape as spawnPluginChild; the package ships src/server/ so the child runs from source):

• 20 s deadline → SIGKILL, then one retry in a fresh process; final failure is a clean {ok:false} with the child's stderr tail, never a hang
• verdict travels as a marker-line JSON on stdout, read on the close event so the pipe is fully drained before settling
• buildPluginBundlesInProcess stays exported only for the child; public callers (plugin-service install, plugin_validate) are unchanged
• isolation is faster, not a tax: a child compile of the hello fixture measures ~100–200 ms where the tests used to budget 60 s
• the deadline path is pinned by a deterministic stalling-build-child fixture test

CLAUDE.md's Plugin System section records the incident, the upstream bug, and why the compile must not move back in-process.

Also: one wall-clock flake defused

agent.test.ts dispose() resolves after gracefulTimeoutMs even if closed never resolves asserted elapsed < 500 around a 100 ms timer — observed at 731 ms under ordinary load, failing the suite twice while validating this change. The ceiling is now 5 s: the promise (dispose proceeds instead of waiting forever) is proven by the ≥ 90 ms bound and by resolving at all; a sub-second ceiling was measuring the scheduler.

Validation

• bun run test — 8379 pass / 0 fail (623 files)
• bun run typecheck, lint, lint:comments, check:arch, check:commits — clean
• deadline test kills a stalling child twice and reports in ~1 s

CI noise scoreboard for today

1. mock.module registry poison → fixed in fix(plugins): inject the contributions loader so a module mock cannot poison CI #1141 (shipped in v1.58.1), gate in test(guard): ban new module mocks and record the mock.module lesson #1143
2. in-process Bun.build wedge → this PR (v1.58.1 publish re-dispatched meanwhile)
3. dispose timing ceiling → this PR