fix(provider/openai-compatible): trust user-declared modalities, don't inject fake ERROR text

unsupportedParts (transform.ts) replaces image/file parts with an inline 'ERROR: Cannot read <name> (this model does not support <modality> input)' text part when model.capabilities.input.<modality> is false. The capability is derived in provider.ts:1298-1304 — for @ai-sdk/openai-compatible (the user-configured proxy) there is no models.dev entry, so image/audio/video/pdf all default to false unless the user explicitly declares modalities in opencode.json.

This is a silent footgun in the user-configured-proxy case. The screenshot is stripped before the wire, and the model receives the fabricated 'ERROR: Cannot read image' text as if it came from the user — producing nonsensical replies like 'I can't see the image' even though upstream supports vision.

Forwarding the part for openai-compatible providers is honest: if upstream truly can't handle it, we get a real provider error from the API call, which is far more debuggable than fabricated capability text. Native providers (@ai-sdk/anthropic, @ai-sdk/openai, @ai-sdk/google, @ai-sdk/amazon-bedrock) keep the existing check because models.dev IS authoritative for them — there the filter prevents a real 4xx upstream and gives the user a clear local error.

Reproed against browser-use cloud's V4 LLM gateway (an openai-compatible proxy in front of Anthropic): vision smoketest replied 'I cannot see the image' on every run; gateway-side request audit confirmed zero image_url / file / data:image/ signals in the body even when the agent attached a screenshot via browser_execute. With this change image parts reach the wire and the model produces real vision replies.

Author: bcode

packages/opencode/src/provider/transform.ts

@@ -390,6 +390,21 @@ function applyCaching(msgs: ModelMessage[], model: Provider.Model): ModelMessage
 }
 
 function unsupportedParts(msgs: ModelMessage[], model: Provider.Model): ModelMessage[] {
+  // @ai-sdk/openai-compatible is the user-configured proxy provider — there is
+  // no models.dev entry to consult, so model.capabilities.input.{image,audio,
+  // video,pdf} all silently default to false (provider.ts:1298-1304) unless
+  // the user explicitly declares `modalities` in opencode.json. Replacing
+  // every image/file part with an inline ERROR text part in that case is a
+  // silent footgun: bcode strips the screenshot before the wire and the
+  // model receives "ERROR: Cannot read image..." as if it came from the user,
+  // producing nonsensical replies ("I can't see the image"). The honest
+  // behavior is to forward the part — upstream returns a real provider error
+  // if it truly can't handle it, which is far more debuggable than fabricated
+  // capability text. Native providers (@ai-sdk/anthropic, @ai-sdk/openai,
+  // @ai-sdk/google, @ai-sdk/amazon-bedrock) keep the check because models.dev
+  // is authoritative for them.
+  if (model.api.npm === "@ai-sdk/openai-compatible") return msgs
+
   return msgs.map((msg) => {
     if (msg.role !== "user" || !Array.isArray(msg.content)) return msg