feat(agent-core-v2): fall back to models.dev catalog for model capability detection

[7Sageer]

Related Issue

No linked issue — the problem is explained below.

Problem

Model capability detection for non-Kimi providers (image_in / video_in / audio_in / thinking / tool_use) relied solely on a hardcoded prefix table in llmProtocol/providers/capability-registry.ts. That table is effectively unmaintained: a new model only gets correct capability gating when someone hand-adds a prefix, and everything else falls through to UNKNOWN_CAPABILITY.

Meanwhile the CLI already bundles a models.dev catalog snapshot (BUILT_IN_CATALOG_JSON, injected at release build time) with rich, community-maintained per-model capability data — but it had zero runtime consumers.

What changed

resolveModelCapabilities in agent-core-v2 now consults the bundled catalog before the hardcoded table. The precedence chain is:

config declaration (alias.capabilities) > models.dev catalog lookup > hardcoded prefix table > UNKNOWN

• llmProtocol/catalog.ts: new getCatalogModelCapability(catalog, protocol, modelName) — maps each wire type to its first-party models.dev provider id (anthropic / openai / google / google-vertex(+-anthropic); the kimi wire is not mapped), normalizes catalog model keys (Bedrock region/vendor prefixes, Vertex @version, -v1:0, date suffixes), and returns the catalog capability on a normalized exact match. Also adds loadBuiltInCatalog for parsing a snapshot JSON string.
• llmProtocol/catalogSnapshot.ts: new ICatalogSnapshot app-scope DI token so hosts inject catalog data (agent-core-v2 stays dependency-free at L0).
• model/modelResolverService.ts: detected = getCatalogModelCapability(...) ?? getModelCapability(...); select_tools and max_context_tokens semantics are unchanged.
• kap-server: ServerStartOptions.catalog seeds the snapshot at bootstrap.
• apps/kimi-code server startup (v2 path): loads BUILT_IN_CATALOG_JSON and passes it through. Dev builds ship no snapshot, so they fall back to the hardcoded table exactly as before.
• The hardcoded prefix table is now marked FROZEN: it remains as the last-resort fallback for snapshot-less hosts and model ids the catalog does not cover, but should not grow — new model coverage comes from catalog snapshot refreshes.
• Tests: 9 new cases for the catalog lookup (mapping, key normalization, miss, kimi, undefined catalog) and 5 new resolver cases (catalog preferred over hardcoded, miss falls back, no catalog unchanged, config declaration still OR-ed).

Notes for reviewers:

• Only the boolean capability fields are consumed from the catalog; context/output limits still come from config (maxContextSize), so per-provider limit differences (e.g. Azure's smaller context windows) are out of scope here.
• API relay/proxy endpoints are covered without being in the catalog themselves: lookup keys off wire type → first-party provider entry, and a transparent relay shares the upstream model's boolean capabilities.
• Verified: agent-core-v2 targeted tests 67/67 (catalog 9 + modelResolver 58), kap-server boot tests 8/8, typecheck for agent-core-v2 / kap-server / apps-kimi-code, lint:domain clean.

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue, or explained the problem above.
• I have added tests that prove my feature works.
• Ran gen-changesets skill, or this PR needs no changeset.
• Ran gen-docs skill, or this PR needs no doc update (internal fallback only; no user-facing config or behavior change).

[changeset-bot]

🦋 Changeset detected

Latest commit: f23a69a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@moonshot-ai/kimi-code	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR