fix(opencode): prevent unbounded memory growth from stuck SSE streams

[autopilotgrowth]

Fixes #22198.

Problem

When an SSE peer disconnects via TCP half-close (CLOSE_WAIT), Hono's stream.onAbort never fires on Bun, and writeSSE can neither resolve nor reject on the half-closed socket. The existing AsyncQueue had no size limit, so heartbeats and Bus events accumulated at ~14 MB/sec per zombie connection (Windows desktop peaks reported at 24.5 GB).

Fix

Three independent guards so the stream tears down no matter which failure mode hits:

• AsyncQueue gets a size getter and a close(sentinel) that drops buffered items and unblocks the consumer immediately, so producers can detect drain failure and stop.
• A shared writeSSEWithTimeout helper races each writeSSE against a 30s timeout so half-closed sockets no longer block the consumer forever.
• On timeout or any write error, the existing stop() clears the heartbeat, unsubscribes from the Bus, and closes the queue.

Applied symmetrically to /event (per-instance) and /global/event.

Verification

• packages/opencode/test/util/queue.test.ts — 8 tests covering size, close, buffered-drop, idempotency
• packages/opencode/test/util/sse.test.ts — 4 tests covering timeout, success, error propagation
• Full bun typecheck passes. bun test test/util 200/200 pass. bun test test/server test/control-plane/sse.test.ts 27/27 pass.

Repro from the issue on Windows 11:

$id = (Get-Process -Name 'opencode-cli').Id
$conns = netstat -ano | Select-String "$id"
"RAM: $([math]::Round((Get-Process -Id $id).WorkingSet64/1GB,2))GB | Alive: $(($conns|Select-String ESTABLISHED).Count) | Zombie: $(($conns|Select-String CLOSE_WAIT).Count)"

Before: RAM grows ~14 MB/sec with stable zombie count. After: queue either caps at 10k entries or write times out at 30s; either way the stream self-terminates and memory returns to baseline.

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• PR fix(sse): prevent memory leak from zombie SSE connections #22552: fix(sse): prevent memory leak from zombie SSE connections

This PR appears to address the same issue of memory leaks from zombie SSE connections. Since the current PR (24058) fixes issue #22198 with similar symptoms (unbounded memory growth from stuck SSE streams), PR #22552 may be a related attempt to fix similar SSE connection issues and should be reviewed for potential overlap or if it has already been resolved.

[github-actions]

This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new pull request that follows our guidelines.