fix: abort SSE event subscription on stream close so process can exit

[ben-vargas]

Problem

Any Node process using the provider against an external OpenCode server hangs after a streamText() call completes: the event loop never drains, so scripts like npx tsx examples/tool-observation.ts print finish: stop and the usage line but never exit. The process holds an ESTABLISHED TCP connection to the OpenCode server indefinitely (13+ minutes observed).

Found during a post-release validation sweep of all 12 examples for v3.0.5, which ran examples against one shared, externally started server (opencode serve --port 4096) instead of letting each example auto-start its own. streaming.ts, tool-observation.ts, and image-input.ts hung deterministically after printing all correct output; abort-signal.ts hung flakily.

Root cause

doStream called client.event.subscribe(...) with no AbortSignal. The @opencode-ai/sdk SSE implementation (createSseClient) only cancels its fetch body reader inside an abort-signal handler. When the provider closes the generator via iterator.return(), the generator's finally block runs reader.releaseLock() but never calls reader.cancel(), so the underlying SSE socket stays open and keeps the Node event loop alive. (The provider uses the /v2 SDK entry point; its SSE client has the same behavior as the v1 one.)

Why this went unnoticed

This is not a v3.0.4/v3.0.5 regression — the un-aborted subscribe has been present since the initial release (14068fc). On the default path, autoStartServer spawns a child server and dispose() calls server.close(); killing the server tears down every socket to it as a side effect, including the leaked SSE socket, so the process exits and the leak is masked.

On the external-server path, dispose() correctly does not close a server it didn't spawn — so nothing tore down the leaked socket. This path is first-class and easy to hit: baseUrl, a preconfigured client, or even autoStartServer: true silently reusing a server already running on port 4096 (anyone with opencode serve up) all leaked on every streamText() call.

Fix

• Create an AbortController per stream in doStream and pass its signal as the fetch options argument to client.event.subscribe
• Abort it in closeIterator — before iterator.return(), since the abort also unblocks a pending iterator.next() that return() would otherwise queue behind — and again (idempotently) in the stream's outer finally, which also covers errors thrown between subscribe and the event loop
• Track active subscription controllers in OpencodeClientManager via a new registerEventSubscription() so dispose() aborts any SSE connections still open, including against non-managed (reused) servers

Verification

Note: reproducing the hang (or verifying the fix) requires an externally started server — the auto-start path masks the leak via server shutdown, so it proves nothing.

• npx tsx examples/tool-observation.ts reusing an externally started OpenCode server on 127.0.0.1:4096 now exits on its own with code 0 in ~8s total, immediately after the finish: stop/usage lines (previously hung indefinitely)
• In the validation sweep, the previously flaky abort-signal.ts hang did not reproduce with this fix built into dist (6/6 watchdogged runs exited cleanly in 3–10s), so this leak fully accounts for the observed hangs
• npm test: all 371 tests pass; tsc --noEmit and eslint clean