fix(combo): lock GitHub models rejected as "not supported" for future requests

[turbolego]

Follow-up to #11762 / #11774 — same bug class, this time in combo's own model routing

Checking a fresh 1h log confirmed another instance of the "permanent failure never gets locked out, so it's retried forever" bug — this time not in checkFallbackError's classification, but in combo.ts's own model-lockout wiring.

The symptom

github rejects several models with a 400 that is permanent for this account's Copilot integration — it will never start working mid-session:

"provider": "github",
"model": "gpt-5.4",
"status": 400,
"error": "[400]: The requested model is not supported."

"provider": "github",
"model": "gpt-5.3-codex",
"status": 400,
"error": "[400]: The requested model is not available for integrator \"vscode-chat\".
          Available models: [gpt-4.1 claude-fable-5 ... gemini-3.6-flash ...].
          Verify the correct Copilot-Integration-Id header is being sent."

This isn't a one-off — the same models (gpt-5.3-codex, gpt-5.4, gpt-5.4-mini, gpt-5.5, gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra, mai-code-1-flash) get rejected with this exact 400 on every single virtual-auto-default-*-github combo step, in every request, for the entire hour (dozens of times across the log). Each occurrence is a wasted upstream call.

Root cause

Combo's #5249 guard (isModelScoped400) correctly lets the combo advance to the next target within the same request — that's intentional and correct, since a different provider might serve the model. But nothing ever recorded a cross-request lockout for the rejected model, because the per-request "same-model retry" lockout path in combo.ts (recordModelLockoutFailure, gated by isTransient) only fires for [408, 429, 500, 502, 503, 504] — 400 is deliberately excluded there (a 400 always advances immediately, never retries the same model in-request). So a model that GitHub will reject forever for this account gets tried again from scratch on every new incoming request, indefinitely.

The fix

In open-sse/services/combo.ts, right after the existing #2101/#5249 stop-guard: when isModelScoped400(errorText) is true, call lockModelIfPerModelQuota(provider, connectionId, rawModel, "model_capacity", 1h).

• github already has per-model-quota enabled (hasPerModelQuota("github") === true), so this locks only the rejected model, not the whole GitHub connection — sibling models keep working normally.
• isModelLocked() is already checked before dispatch on every future request (combo.ts pre-check), so the lockout is honored automatically — no other wiring needed.
• The in-request combo-advance behavior from fix(combo): advance to next model on 400 'model not supported' #5249 is completely unchanged; this only adds a side effect for future, separate requests.

Testing

Added tests/unit/github-model-not-supported-lockout.test.ts (3 tests, all passing):

• isModelScoped400 matches both GitHub phrasings from the logs.
• github confirmed as a per-model-quota provider.
• lockModelIfPerModelQuota locks the rejected model while leaving a sibling model on the same connection eligible.

Also fixed tests/unit/combo-model-scoped-400-advance.test.ts: its sub-tests reuse the same model name (github/claude-fable-5) across several test() blocks without clearing lockout state — with the new persistent lockout, the first sub-test's 400 now (correctly) locks that model, causing later sub-tests in the same process to skip it. Added a clearAllModelLockouts() beforeEach to keep each sub-test isolated; no behavioral assertions changed.

Ran locally:

node --import tsx/esm --test tests/unit/github-model-not-supported-lockout.test.ts
# 3/3 pass

node --import tsx/esm --test tests/unit/combo-body-specific-400-stop-4279.test.ts \
  tests/unit/account-fallback-service.test.ts tests/unit/agentrouter-lock-scope-10334.test.ts
# 113/113 pass

node --import tsx/esm --test tests/unit/combo-model-scoped-400-advance.test.ts \
  tests/unit/combo-param-validation-fallback-4519.test.ts
# 12/12 pass (was 2 failing before the beforeEach fix — confirmed root cause, not a real regression)

node --import tsx/esm --test tests/unit/combo-quota-token-limit.test.ts \
  tests/unit/combo-lockout-quota-reset-6863.test.ts tests/unit/model-lockout-max-cooldown.test.ts \
  tests/unit/combo-terminal-status-policy-10501.test.ts tests/unit/combo-resource-404-health.test.ts \
  tests/unit/combo-input-bound-failure-8375.test.ts tests/unit/combo-input-bound-heterogeneous-8375.test.ts
# 12/12 pass, no regressions

Also registered the new test in stryker.conf.json's tap.testFiles (required for the mutation-test-coverage gate, per CI feedback on #11762).

Files changed

• open-sse/services/combo.ts — new lockModelIfPerModelQuota import + call at the model-scoped-400 site.
• tests/unit/github-model-not-supported-lockout.test.ts — new regression test.
• tests/unit/combo-model-scoped-400-advance.test.ts — added lockout-state isolation between sub-tests.
• stryker.conf.json — register the new test file.