Desktop connection detail asks for capability declarations the Host can already provide #4496

What happens

Open Settings → a provider connection whose provider serves a model that models.dev has started listing since this Maka build was cut. The connection detail shows that model a row asking the user to declare its capabilities by hand — reasoning, vision, thinking levels — even though the Runtime Host already knows all of them and is describing the model correctly everywhere else in the app.

Why

installRefreshedModelMetadata() swaps a module-level variable in the process that calls it (packages/core/src/model-metadata.ts:71). The Runtime Host calls it at startup, so the Host's activeMetadata() is the refreshed catalog. The Desktop renderer is a different process — often on a different machine — and its own activeMetadata() is, and always will be, the snapshot compiled into that build.

That is by design: since #4411 clients are supposed to read Host-resolved catalogEntries rather than resolve a catalog themselves. apps/desktop/src/renderer/settings/provider-connection-detail.tsx:222 is one of the last places that did not get converted. It asks hasModelMetadata(connection.providerType, modelId) — a question about the renderer's own bundled table — to decide whether a model needs a hand-written capability declaration:

const capabilityModelIds = enabledModelIds.filter(
  (modelId) =>
    isRelay ||
    relayProfileDraft[modelId] !== undefined ||
    !hasModelMetadata(connection.providerType, modelId),
);

The intent of that third condition is "the app cannot describe this model, so ask the user". After #4467 the app can describe it; only this renderer cannot.

What the fix needs to decide

The data is already at hand: useConnectionDetail computes modelChoices from connection.catalogEntries (apps/desktop/src/renderer/settings/use-connection-detail.ts:314), and the component already receives it. What is missing is a way to ask a ModelCatalogEntry the actual question.

ModelCatalogEntry (packages/core/src/model-catalog.ts:64) carries displayName?, description?, contextWindow?, supportsVision, thinkingLevels — but no field that states "metadata describes this model". Inferring it from whether some optional field happens to be present would put a second, weaker copy of the rule in the renderer, which is the split this whole line of work exists to close. The Host knows the answer directly; the entry should say so.

That makes it a wire change, and therefore an epoch bump — worth knowing before starting. The renderer edit itself is a few lines.

Not in scope

apps/desktop/src/renderer/settings/provider-endpoint-presentation.ts:98 also calls into the bundled table, via modelMetadataIdsForProvider(). That one is correct as written: it uses those ids only to look up lookupModelProviderOverride, which reads generatedModelProviderOverrides — build-time generated data that a Host refresh deliberately does not install. Both sides come from the same generation, so they stay consistent. Please leave it alone.

Impact

Cosmetic and recoverable: one extra form row on a normal user path. No persisted state is wrong, and nothing else reads the affected condition.

Refs #4398, follows #4411 and #4467.