fix(litellm): derive video input modality from supports_video_input

[PranjalAgarwal01]

What

LiteLLM's /model/info exposes supports_video_input for models that accept video input, but the enricher's flag-based fallback only derived text, image from supports_vision — video-capable models were mapped to text, image only.

This affects deployments that do not declare modalities (common on older LiteLLM proxies). In practice: a vLLM-backed LiteLLM gateway where video works end-to-end, supports_video_input: true is advertised, yet OpenCode never sees the video input capability.

Change

In the fallback path only (explicitly declared modalities still win, unchanged):

model_info flags	derived input
supports_vision: true	text, image
supports_video_input: true	text, video
both	text, image, video
modalities.input declared	unchanged (declared wins)

• src/types/index.ts — add supports_video_input to LiteLLMModelInfo
• src/utils/model-info/litellm.ts — derive video from the flag in the fallback
• test/litellm-model-info.test.ts — new cases: video-only, vision+video, declared-modalities precedence

Verification

• npx vitest run test/litellm-model-info.test.ts — 18 passed
• npm run typecheck clean; npm run lint no new findings
• npm run test:run — 299 passed; the 3 failures (plugin.test.ts auth-store cases, node-loadable.test.ts) reproduce identically on an unmodified dev checkout on Windows and are unrelated to this change

[yuhp]

Thanks @PranjalAgarwal01 for the clean fix and thorough test coverage!

Deriving video from supports_video_input in the fallback path makes complete sense for LiteLLM setups that don't declare full modalities objects.

Merging this into dev now — it will be included in our next release! 🚀