fix(core): add DeepSeek V4 Flash Vision to model metadata

[yunaremaia]

Summary

Registers deepseek-v4-flash-vision-exp in the model metadata so Maka correctly recognizes its image input capability and passes attachments through to the DeepSeek adapter.

Fixes #3417

What changed

• STATIC_MODEL_METADATA.deepseek: added deepseek-v4-flash-vision-exp with vision: true, reasoning, function calling, and web search capabilities (same baseline as deepseek-v4-flash).
• CURATED_CATALOG_FALLBACK_MODELS.deepseek: added the new model ID so it appears in the fallback catalog when live model discovery is unavailable.

How it fixes the bug

resolveModelVisionSupport() checks STATIC_MODEL_METADATA when the model ID is not in the stored inventory. Without this entry, the function returned false and appendImageParts() filtered the attachment before the request reached DeepSeek.

Testing

• The new metadata entry follows the exact shape of the existing deepseek-v4-flash entry, with vision: true added.
• No test changes needed: the existing resolveModelVisionSupport tests exercise the metadata lookup path, and the new entry is structurally identical to existing entries.
• Build and typecheck will validate in CI; I was unable to run npm install locally (blocked by @xterm/xterm registry fetch on this host).

AI disclosure

OpenAI Codex assisted with codebase analysis. I reviewed the diff and take responsibility for the contribution.

Signed-off-by: Yunare Maia yunare@gmail.com

[Astro-Han]

Reviewed at exact head d74bb28c0af711063db5c77084fdd06962a279e2. No [P0]–[P2]. The entry is internally consistent — it mirrors its deepseek-v4-flash sibling exactly (same efforts: ['high','max'], same toggle, same webSearch) and adds vision: true, which is the one thing that distinguishes this variant.

Two things worth confirming, neither of which I can settle from inside the repo.

The model ID has to be exactly what the API accepts. Adding deepseek-v4-flash-vision-exp to CURATED_CATALOG_FALLBACK_MODELS means it is offered to users specifically in the case where the live catalog fetch failed — so if the string is wrong, the failure shows up precisely when there is no live catalog to correct it. Worth a maintainer confirming the ID against a real DeepSeek response rather than against documentation.

vision: true is a hard declaration here. resolveVisionSupport checks a user declaration, then inventory, then this metadata — so for a model that isn't in the live inventory, this entry is the answer, and an over-claim surfaces as a failed request after the user attaches an image rather than as a disabled control.

[P3] No lastUpdated

The neighbouring deepseek-v4-pro carries lastUpdated: '2026-08-13' while both flash entries omit it. Not introduced by this PR — deepseek-v4-flash already omits it — so this is an observation about the block rather than a request. Worth adding if the field is meant to track when a capability claim was last checked against the provider, which is exactly the kind of claim an -exp model is most likely to change.

CI note: this head's workflow was sitting at action_required as a fork run; I approved it so it could execute. Draw gate conclusions from that run's terminal state, not from this comment.