Fallback model lists still offer deprecated models for six providers

fallbackModels entries are offered to users as usable choices: discovery keeps only the fallback set (model-fetcher.ts), and the catalog marks what survives available and canUseAsChatDefault: true. Deprecated snapshot models in that list are therefore presented as selectable defaults.

toolCallingModelIds (packages/core/src/provider-registry.ts) filters on tool-calling capability only. Seven providers exclude deprecated ids by filtering at the call site; the rest do not, and openai writes its list by hand without going through the helper at all.

Measured on #3324's head, which fixes ZenMux — 28 deprecated models still ship in fallback lists:

provider	count	examples
togetherai	11	deepseek-ai/DeepSeek-V3, essentialai/Rnj-1-Instruct
mistral	8	devstral-2512, devstral-latest
xiaomi	3	mimo-v2-flash, mimo-v2-pro
deepinfra	3	MiniMaxAI/MiniMax-M2.5
nvidia	2	moonshotai/kimi-k2.6
openai	1	gpt-4-turbo

Why this is not just a missing filter

Converging every list onto toolCallingModelIds would not cover openai, whose list is hand-written. The decision worth making explicitly is whether deprecated should exclude a model from being offered at all — it is an upstream lifecycle marker, not a statement that the endpoint rejects the call — and answering yes changes which models six providers present.

Current boundary

packages/core/src/__tests__/provider-catalog-contract.test.ts records these six as PROVIDERS_WITH_DEPRECATED_FALLBACKS. It fails when another provider regresses into the set, and also when a listed provider is cleaned up but left in the list, so the list shrinks as this work lands rather than going stale.

Split out of the #3324 review by @hqhq1025.