fix(opencode): apply default header timeout to all providers

[tancheng33]

Issue for this PR

Closes #39859

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Only the openai provider gets a default headerTimeout (300s). Every other provider — including the zen/opencode provider from the issue — waits for response headers forever. When a connection is established but silently blackholed, the CLI hangs indefinitely with no error: exactly the symptom in #39859 (log stops after llm runtime selected, nothing ever happens). #36029 root-caused one common trigger on Windows: the CLI connects over an IPv6 path that stays Established but never delivers data, while browsers/Electron retry over IPv4 and work — which is why the Web UI works on the same machine.

This applies the same 300s header-timeout default to all providers at the fetch layer (packages/opencode/src/provider/provider.ts), so a blackholed connection now fails with the existing actionable ProviderHeaderTimeoutError instead of hanging forever. Behavior details:

• config headerTimeout: <ms> still overrides, and headerTimeout: false still disables entirely (?? preserves false);
• the OpenAI loader keeps its explicit default, unchanged;
• the timeout only covers time-to-headers — slow/long streams are unaffected once headers arrive (covered by an existing test).

One existing test was renamed (headerTimeout is opt-in for non-OpenAI providers → default headerTimeout does not abort briefly delayed headers) since it now documents the new default; its assertions are unchanged and still pass. If keeping header timeout opt-in for non-OpenAI providers was a deliberate decision, happy to hear the reasoning — but a silent infinite hang seems strictly worse than a 5-minute failure with a clear error, and anyone with a legitimately slower provider can raise or disable it in config.

How did you verify your code works?

• bun test test/provider/header-timeout.test.ts — 6/6 pass (including headers-never-arrive abort and delayed-SSE-body no-abort).
• bun test test/provider/provider.test.ts — 99/99 pass.
• bun typecheck in packages/opencode passes; full-repo typecheck passes via the pre-push hook.

Screenshots / recordings

Not a UI change.

Checklist

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

[github-actions]

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

Based on my search, I found two potentially related PRs:

1. fix(provider): recover stalled model streams #40010 - fix(provider): recover stalled model streams

   • This PR also addresses provider-related connection/streaming issues and may be related to handling stalled or hung connections.

2. fix(provider): apply documented 300s request timeout default #36650 - fix(provider): apply documented 300s request timeout default

   • This is highly relevant as it deals with applying a 300s timeout default to providers, which is similar in scope to the current PR's goal of applying header timeout defaults.

The current PR (#40069) appears to be the primary/newer iteration addressing the header timeout issue across all providers, whereas #36650 may have focused on a different timeout aspect (request timeout vs. header timeout). PR #40010 addresses a related stability concern with stalled streams.