fix(context): uncataloged combo members no longer clamp the runtime combo limit to generic 128k

[skygunner]

TL;DR (plain language)

The context guard resolves a combo's window as roughly "the smallest member's window". A member whose window nobody knows answered 128,000 anyway — a generic constant that has nothing to do with the deployment — and dragged the whole combo down to that guess. After this PR, an unknown member says "unknown" instead of guessing, so the combo runs at the smallest window it actually knows about, and only falls back to the generic 128,000 when no member's window is known.

This is the runtime sibling-side mirror of the rule #10734/#10793 already applied to advertised combos via getSourcedTokenLimit() — owner-confirmed in #14931 (root cause #2).

The incident, concretely (from #14931): combo coding-pool = qwen3.8-27b (uncataloged → generic 128000) + deepseek-v4-flash-0731 (catalog match → 1,000,000). Math.min picked 128,000, the guard 400'd a request the provider measured at 49,822 real tokens, and Codex CLI's retries turned that into a 503 storm. One log line told the story: Combo context limit: 128000 (source=combo-min).

This is Part 1 of a 3-part series on #14931 — Part 1: sibling-side limit resolution (this PR) · Part 2: estimator calibration against provider-reported usage · Part 3: proactive-compression log basis labels. Sibling PRs: #15054 and #15055. Please keep the issue open until all three land.

Change

getComboTargetTokenLimit() (its only caller is chatCore's combo-limit array) now resolves through getSourcedTokenLimit(): a target whose window resolves solely to the non-specific DEFAULT_LIMITS.default returns undefined, and chatCore's existing numeric filter drops it from the array. resolveComboContextLimit()'s precedence chain is untouched:

1. combo context_length (operator declaration) →
2. executing target's own specific window →
3. min(...known sibling windows) — previously min(...all windows, unknowns = 128000) →
4. generic fallback when nothing is known (unchanged, source=fallback).

scenario	before	after
executing member has a specific window	its own window (step 2 early-return)	no change
executing member unknown, a sibling is known (the incident)	min(128000, sibling) → 128000 false kill	min(known siblings) → sibling window
every member unknown	128000 (fallback)	128000 (fallback) — no change
combo has explicit context_length	explicit value	no change

Why inheriting a sibling's window is the right default

This answers the concern raised in the #14931 thread that dropping the generic value "turns a too-small limit into a too-large one" when the executing member is the unknown one:

1. Error direction is not symmetric. A too-small guard limit produces a local 400 the client cannot recover from (the Codex retry storm in the issue). A too-large limit produces an upstream 400, which the existing combo failover already handles — that is exactly how the incident's traffic eventually got served.
2. Information quality. 128,000 is a constant unrelated to the deployment. min(known siblings) is at least the real window of an operator-curated sibling in the same pool — for the incident combo that is 1,000,000 vs qwen's real 262,144: overly wide, but a far better prior than a blind guess.
3. The precise levers are unchanged and documented: combo context_length, per-model context overrides / CONTEXT_LENGTH_* env, catalog entries. This PR only removes the baseless constant from the chain.

Testing

• tests/unit/combo-target-token-limit-8716.test.ts — the fix(backend): combo compression-limit null.toUpperCase() when target modelStr has no provider prefix #8716 no-crash contract keeps passing; the both-providers-missing case now asserts undefined (was: a positive number), with a comment pointing at fix(backend): Context guard rejects Codex CLI at ~50k real tokens: chars/4 estimator over-counts ~1MB of tool schemas 5-6x, checked against a generic 128k fallback limit (model catalog miss → combo-min) #14931.
• tests/unit/chatcore-combo-sibling-specific-14931.test.ts — new, end-to-end through handleChatCore: a ~150k-estimated request against an [unknown member, 1M sibling] combo is no longer rejected (context_length_exceeded / limit 128000 must not appear), while a ~1.15M-estimated request is still rejected citing the inherited 1,000,000 — the guard keeps its teeth.
• tests/unit/resolveComboContextLimit.test.ts, tests/unit/combo-context-generic-default-10734.test.ts — precedence chain regressions green.
• Gates: check-open-sse-typecheck (0 errors), check-complexity-ratchets, check-t11-any-budget pass; no frozen file touched.