[shreyaskarnik]

Fixes #59, using option 1 from the issue: engines.openai() gains a fetchOptions option that is passed straight to the OpenAI SDK.

Why

From openai v5 the SDK uses Node's built-in fetch (undici), whose default headersTimeout is 300 s. That limit is enforced by the connection pool, independently of the SDK's own timeout, so timeoutMs alone can't lift it. The SDK merges fetchOptions into every fetch call, and undici reads a dispatcher from it, so a user-supplied Agent replaces the default pool:

import { Agent } from 'undici';

engines.openai({
  baseUrl: 'http://localhost:8881/v1',
  timeoutMs: 1_800_000,
  fetchOptions: { dispatcher: new Agent({ headersTimeout: 0, bodyTimeout: 0 }) },
})

Argo gains no dependency: users who need long waits install undici themselves. On openai 4 the option is ignored, which is fine since v4 has no such limit.

Verification

• tests/tts/openai.test.ts: new test asserting fetchOptions reaches the client. All 223 tests in tests/tts pass; tsc --noEmit is clean.
• Real SDK (openai 6.49.0, undici 7.30.1, Node 20), against a stub server that delays response headers, with the same client options the engine builds:

Server delay	fetchOptions	Result
3 s	dispatcher with headersTimeout: 1000	APIConnectionTimeoutError after 1.5 s (proves the dispatcher is used)
3 s	dispatcher with headersTimeout: 0	ok after 3.0 s
320 s	none (today's behaviour)	APIConnectionTimeoutError after 301.6 s
320 s	dispatcher with headersTimeout: 0	ok after 320.0 s

README and skills/argo-guide/references/tts-engines.md now show the workaround next to the documented limit.

Thanks to @lordrip for the detailed reproduction in #59, which this follows exactly.

https://claude.ai/code/session_01A5noi8MogUjD2mdirpzXmY