fix(provider): pin undici headersTimeout/bodyTimeout so long-running Node requests survive past 300s - #50656

Issue for this PR

Closes #26602

Type of change

• Bug fix

What does this PR do?

Node's undici fetch defaults both headersTimeout and bodyTimeout to 300000ms. That silently kills any provider request — including an SSE stream with a >300s gap between chunks — at the ~303s mark, regardless of a provider's own timeout: false / AbortSignal-based config, because those are cancellation mechanisms and don't touch undici's socket-level Agent dispatcher settings. Bun's fetch has no such default, which is why this only reproduces on Node (Desktop's sidecar process, or the SDK used from a Node host).

This adds a shared createUndiciDispatcher util (packages/core/src/util/undici-dispatcher.ts) that builds a custom undici Agent from the provider's timeout option — false disables both timeouts outright, a positive number uses that value in ms, anything else leaves undici's defaults alone. It's guarded to a no-op under Bun via process.versions.bun.

Wired into three places that construct the outgoing fetch:

• V2's provider-call path, packages/core/src/aisdk.ts
• V1's provider-call path, packages/opencode/src/provider/provider.ts
• the SDK's own client→server fetch, packages/sdk/js/src/node-fetch.ts (new, used by both client.ts and v2/client.ts), which needs both timeouts disabled outright since a blocking session request can legitimately run past 5 minutes

This doesn't conflict with the existing chunkTimeout/headerTimeout abort-signal handling in either provider path — those are AbortSignal/AbortController-based and independent of undici's dispatcher-level socket timeouts.

This revives the approach from #33535, which was auto-closed by this repo's engagement-based PR-cleanup bot (fewer than 2 reactions after a month) rather than for a technical reason — same fate as the earlier #26599. Rebased against current dev. One correctness fix versus #33535: its node-fetch.ts dropped the pre-existing req.timeout = false mutation that disables Bun's own per-request idle timeout (oven-sh/bun#16682) on the non-dispatcher (Bun) path. This PR keeps it — it's a no-op under Node/undici and still required under Bun.

How did you verify your code works?

• bun test in packages/core — 1108 pass, 0 fail (10 new tests for createUndiciDispatcher/resolveTimeoutMs, covering the false/number/undefined/Bun-guard cases)
• bun test in packages/sdk/js — 1 pass, 0 fail
• bun test test/provider in packages/opencode — 714 pass, 0 fail
• bun typecheck clean in packages/core, packages/opencode, packages/sdk/js (packages/opencode has pre-existing Buffer/Uint8Array typecheck errors in unrelated files — test/image/image.test.ts, packages/tui, etc. — confirmed present on unmodified dev via git stash, not introduced by this change)
• oxlint on touched files: 0 new errors

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR