Intermittent multi-second first-request stall on Bun serve under CPU load (node:http dispatch starvation)

Description

On Bun, opencode serve intermittently hangs its first request for tens of seconds under CPU load, then recovers (startup-only; once warm it's fine).

I traced it end to end: the request-handler fiber is never forked — the TCP connection is accepted and the request bytes are read into userspace (rx_queue=0), but Bun's node:http never emits the JS request event while the loop is parked in epoll_pwait2, so Effect never sees the request. Bisected to Bun: 1.3.11 does not stall; 1.3.12/1.3.13/1.3.14 do (rebuilding opencode on 1.3.11 drops the rate from ~100% to ~5% under the same load) — so it's a Bun regression under load, not app logic. Effect's default scheduler flushes fiber dispatch via globalThis.setImmediate, which hits the same starvation.

Proposed fix in #46436 (route the scheduler flush through a MessageChannel macrotask).

OpenCode version

1.18.18 (Bun 1.3.14)

Steps to reproduce

1. Run opencode serve on a CPU-constrained container (e.g. a 2 vCPU cgroup) under load.
2. Fire the first request as soon as it's listening (a warm-up GET /session/:id is enough).
3. Under heavy contention the first request hangs ~100% of the time for 30–60s before self-clearing; under lighter load it's intermittent (a few percent of cold boots).

Operating System

Debian 12 (bookworm) container, Linux 6.17 x86_64, cgroup-limited to 2 vCPU / 4 GiB, Docker + overlayfs.