fix(nvidia): drop EOL models, repoint DeepSeek V4 Flash at its live id

[ggfto]

Problem

Three models in the NVIDIA registry have been retired upstream. NVIDIA answers 410 Gone with an explicit end-of-life date, so 9Router advertises them in /v1/models and every route to them fails at call time — including combo fallback chains, where a dead entry silently consumes a fallback slot.

Model	Upstream response
minimaxai/minimax-m2.7	410 — "has reached its end of life on 2026-07-27T00:00:00Z"
deepseek-ai/deepseek-v4-pro	410 — "has reached its end of life on 2026-08-07T09:00:00Z"
deepseek-ai/deepseek-v4-flash	410 — "has reached its end of life on 2026-08-07T09:00:00Z"

Change

• deepseek-ai/deepseek-v4-flash → deepseek-ai/deepseek-v4-flash-0731. The model lives on under a dated id, present in NVIDIA's live /v1/models and verified answering, so it is repointed rather than dropped.
• minimaxai/minimax-m2.7 and deepseek-ai/deepseek-v4-pro removed. Neither has a successor in the live catalog. minimaxai/minimax-m3 already covers the MiniMax slot and is unaffected.
• Matching PROVIDER_CAPABILITIES.nvidia entries updated in open-sse/providers/capabilities.js.
• tests/translator/real/nvidia-thinking.e2e.test.js updated so the e2e list stops exercising retired ids.

Scope — what is deliberately not changed

Two other NVIDIA models fail from my account but are not registry defects, so I left them alone:

• moonshotai/kimi-k2.6 and nvidia/nemotron-3-ultra-550b-a55b are still listed in NVIDIA's live /v1/models. They return 404 with "Function '<uuid>': Not found for account '<id>'" — per-account access, not a stale entry. Removing them would break users whose accounts do have access.

The bare minimax-m2.7 / deepseek-v4-pro / deepseek-v4-flash keys under codebuddy-cn and poolside in capabilities.js belong to other providers and are untouched — those upstreams may still serve them.

Verification

• Live catalog compared against NVIDIA's /v1/models (102 entries) via GET /api/providers/<id>/models.
• Every id confirmed by real inference through a local instance, not by reading docs. deepseek-v4-flash-0731 returns a normal completion.
• Each failure re-tested after a pause before being treated as real: testing in a burst trips NVIDIA's rate limit, after which every model returns an error — including known-good ones. Single-shot results are not trustworthy here.
• npx eslint clean on the changed files.
• Baselines pass: verify-providers (81 providers byte-for-byte), verify-alias (117 tokens), verify-oauth-urls.
• Full vitest suite run before and after on the same checkout: 1796 pass / 90 fail both times, identical failure sets — 0 regressions. (verify-no-regression.mjs could not be used directly: its key builder does f.name.split("/app/")[1], which yields undefined outside the upstream /app/ layout, so I diffed the two runs' failure sets instead.)

Note for maintainers

This is the second time in ~3 weeks that a hardcoded registry list has gone stale against its upstream (Cerebras narrowed its catalog in July and its 6 registry entries no longer resolve either). The plumbing for a live check already exists — src/app/api/providers/[id]/models/route.js fetches integrate.api.nvidia.com/v1/models today. I've opened a separate issue proposing an opt-in reconciliation rather than folding that design discussion into this fix.