Feature request: let users register vision-capable models in provider config

Problem

jcode decides image support per provider, not per model. On the OpenAI-compatible runtime, supports_image_input() returns true for every non-ChatGPT-web model. The only place to say a specific model handles images is the models[].input list in a named provider profile, and only the OpenRouter runtime reads it. So a text-only model on an OpenAI-compatible endpoint gets image blocks sent to it and the request fails, and a vision model that jcode has no catalog entry for can never be marked as vision-capable.

What I want

A way to register a model as vision-capable in config, and have that flag drive supports_image_input() everywhere.

• Honor the existing models[].input field for OpenAI-compatible named providers, not just OpenRouter.
• A model with input: ["text", "image"] reports vision support. A model with input: ["text"], or one that is not listed, falls back to the provider default.
• A provider-level default would help too, something like image_input: true | false | auto, so users do not have to list every model just to flip the default.

Why it matters

Issue #755 shows the failure mode: a text-only model receives an image block and the session breaks. The opposite problem exists too. A vision model behind a gateway with no jcode catalog entry cannot be advertised as vision-capable, so screenshots and pasted images are stripped or rejected even though the model could handle them.

Notes

• Provider::supports_image_input() already exists on the trait.
• NamedProviderModelConfig.input already exists in crates/jcode-config-types/src/lib.rs.
• The OpenRouter runtime maps models[].input to image support, but the plain OpenAI runtime never consults it.

Start with Provider::supports_image_input() and NamedProviderModelConfig in crates/jcode-config-types/src/lib.rs, then compare how the OpenRouter runtime maps models[].input with the plain OpenAI runtime. Done means named OpenAI-compatible models honor text/image input declarations, unlisted models retain provider defaults, and provider-level defaults work consistently across runtimes.