fix(session): retry top-level stream request timeouts

[fashen97]

Issue for this PR

Closes #39221

Type of change

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

What does this PR do?

Some OpenAI Responses-compatible providers return HTTP 200 and then emit this
SSE error event:

{"type":"error","sequence_number":0,"code":"request_timeout","message":"stream error: stream disconnected before completion"}

parseStreamError() only read body.error.code, so the top-level timeout was
not classified as retryable and the turn stopped. This change recognizes the
top-level request_timeout code and uses the existing retry policy.

This complements #39413, which handles an HTTP 408 response status. This PR
handles the separate HTTP 200 plus SSE error response shape.

How did you verify your code works?

• bun test test/session/retry.test.ts (34 pass)
• bun typecheck
• bunx prettier --check packages/opencode/src/provider/error.ts packages/opencode/test/session/retry.test.ts
• The regression test exercises MessageV2.fromError() through
  SessionRetry.retryable() and verifies the parsed error is retryable.

Screenshots / recordings

Not a UI change.

Checklist

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

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

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

Potential Related PRs:

1. fix(session): retry HTTP 408 request timeouts #39413: fix(session): retry HTTP 408 request timeouts

   • fix(session): retry HTTP 408 request timeouts #39413
   • Why related: This PR is explicitly mentioned in your description as complementary. fix(session): retry HTTP 408 request timeouts #39413 handles HTTP 408 responses, while your PR (40268) handles HTTP 200 responses with request_timeout error events in the SSE stream.

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

   • fix(provider): recover stalled model streams #40010
   • Why related: Addresses stream recovery issues similar to the timeout handling your PR implements.

3. fix(opencode): make long-lived provider streams robust to silent SSE terminations #39970: fix(opencode): make long-lived provider streams robust to silent SSE terminations

   • fix(opencode): make long-lived provider streams robust to silent SSE terminations #39970
   • Why related: Handles SSE stream resilience, which overlaps with your timeout error classification work.

These are related PRs addressing similar stream reliability concerns, but #39413 is the most directly relevant since your PR explicitly complements it.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.