fix(provider): enable image support for custom OpenAI-compatible providers

[jwcrystal]

Issue for this PR

Closes #20802

Type of change

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

What does this PR do?

Custom OpenAI-compatible providers (e.g., longent, Ollama with vision models) were unable to process image attachments. Users received the error: "I can't read `image.png` here because this model does not support image input" even when the provider actually supported vision capabilities.

Root cause: In packages/opencode/src/provider/provider.ts:1110, the default value for capabilities.input.image was false for custom providers without explicit modalities declaration. This caused transform.ts:265 to filter out image parts before they could reach the existing conversion logic in convert-to-openai-compatible-chat-messages.ts.

Fix: Changed the default to true specifically for providers using @ai-sdk/openai-compatible:

image: model.modalities?.input?.includes("image") ??
       existingModel?.capabilities.input.image ??
       (provider?.npm === "@ai-sdk/openai-compatible" ? true : false)

This is a one-line change that:

1. Checks if user explicitly declared modalities.input.image (highest priority)
2. Falls back to existing model definition from models.dev (if available)
3. For custom OpenAI-compatible providers, defaults to true instead of false

Why this works: The existing conversion logic in convert-to-openai-compatible-chat-messages.ts:45-64 already correctly transforms file parts to image_url format. The issue was that custom providers were being flagged as "not supporting image input" before the conversion could happen.

How did you verify your code works?

1. Created worktree to test the change
2. Configured a custom OpenAI-compatible provider without modalities declaration
3. Sent image attachments through the OpenCode session API
4. Verified that images now correctly reach the provider (previously were filtered out)
5. Confirmed the change is backward compatible:
   • Providers with explicit modalities still use their declaration
   • Official providers from models.dev keep their capabilities
   • Typecheck passes for all 19 packages

Checklist

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

[github-actions]

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

[jwcrystal]

@adamdotdevin review this please when you are available

[jwcrystal]

@rekram1-node Please review this. I’ll really appreciate it because the image isn’t being loaded by OpenAI-compatible providers.

[KaguraTart]

Hi! I noticed this PR addresses the same issue from a different angle.

My PR #26826 fixes image support at the protocol conversion layer in packages/llm/src/protocols/openai-chat.ts, ensuring MediaPart is correctly transformed to image_url content blocks in the request body.

The root cause I found: lowerUserMessage only accepted TextPart content and rejected MediaPart with unsupportedContent. My fix adds proper content block schema and conversion logic.

Both PRs address the same goal but at different layers - #21627 at the provider capability detection layer, #26826 at the protocol conversion layer. They're complementary and together provide a complete fix.

My PR also includes comprehensive unit tests (16 tests passing) covering media handling scenarios.