fix(llm): compact on provider image limits

[MagMueller]

Problem

Fireworks rejects Kimi conversations after more than 60 images with HTTP 400: Too many images were provided, we currently limit the number of images per conversation to 60.

BrowserCode currently classifies that as a fatal APIError, so its existing automatic media-stripping compaction never runs. Production saw this exact signature across multiple Kimi runs.

Fix

Classify the provider image-count rejection as context overflow. That routes it through the existing overflow recovery path: compact with media stripped, retry the interrupted turn, and preserve the stable compacted prefix instead of truncating every request to the newest 60 images.

This composes with #125, which ensures a recovered overflow does not emit a terminal error or exit nonzero.

Verification

• packages/llm: bun test test/provider-error.test.ts (2 passed)
• packages/llm: bun typecheck
• packages/opencode: bun test test/session/message-v2.test.ts (36 passed)
• packages/opencode: bun typecheck
• repository pre-push filtered typecheck with Bun 1.3.14 (16 packages passed)
• git diff --check

Release

Include this and merged #125 in stable v0.1.14; Cloud should update its exact bcode pin only after that release has published all binaries.

---

Summary by cubic

Classifies Fireworks/Kimi “Too many images … limit 60” errors as context overflow so we compact by stripping media and retry, instead of failing. This avoids 400s on long image threads and preserves the stable compacted prefix.

• Bug Fixes
  • Add /too many images (?:were )?provided/i to overflow patterns in packages/llm.
  • Update tests in packages/llm and packages/opencode to cover the new classification.

^{Written for commit 2968a2a. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}