Registry-sourced models resolve empty input capabilities; file-part rejection echoes wrong media type

opencode 1.18.21, provider opencode (Zen), model x-preview-f-free (registry/free tier)

Summary

For registry-sourced models, request-time capability resolution comes up empty even though the model's provider.toml in models.dev declares vision:

[modalities]
input = ["text", "image", "video"]

The empty resolution causes valid image file parts to be rejected locally with a misleading error, and the error text reports a placeholder media type instead of the part's actual type.

Repro

Send a message with a file part whose actual mime is image/jpeg (verified: valid JPEG bytes, data:image/jpeg;base64,/9j/4AA…):

{ "type": "file", "mime": "image/jpeg", "filename": "IMG_5548.JPG", "url": "data:image/jpeg;base64,…" }

Result:

UnknownError: 'file part media type application/octet-stream' functionality not supported

Two problems visible:

1. The rejection fires at all — the provider endpoint advertises input.image: true and the toml declares image input.
2. The message names application/octet-stream, which is not this part's media type.

Evidence it's capability resolution, not the model

Setting an explicit per-model override makes vision work immediately, with no other change:

// opencode.json
{ "provider": { "opencode": { "models": { "x-preview-f-free": {
  "input": { "text": true, "image": true, "audio": false, "video": false }
} } } } }

After that, the exact same part is accepted and the model describes the image correctly.

Asks

1. Derive request-time capabilities for registry-sourced models from the provider.toml modalities (or provider-advertised capabilities) instead of resolving empty.
2. Echo the actual part media type in functionality rejections.
3. Ideally, log which source decided the capability set when a part is refused — this class of misdiagnosis cost us a long debugging session (full write-up available if useful).

Happy to provide additional traces.