fix(routing): read Codex max/ultra models from the alias sets in reasoning rules

[QuangBlue]

Problem

Reasoning-routing rules decide whether a Codex model accepts max / ultra with a hard-coded GPT-5.6 regex. The regex appears twice in src/lib/reasoningRouting/policy.ts and once more in the rules editor (src/shared/components/ReasoningRoutingRules.tsx). The Codex executor's suffix parsing reads CODEX_MAX_ALIAS_MODELS / CODEX_ULTRA_ALIAS_MODELS in open-sse/executors/codex/reasoningSuffix.ts instead, and its effort clamp table agrees with those sets. The sets already include gpt-6-astra, so the rule gate and the executor disagree about GPT-6 Astra:

• Combo target: a rule that forces max or ultra counts cx/gpt-6-astra and its effort variants (e.g. cx/gpt-6-astra-high) as incompatible, and filterComboForReasoningDecision() removes them from the rule's target combo.
  • Example: with a combo [cx/gpt-6-astra, cx/gpt-5.6-sol, cx/gpt-5.6-luna, cx/gpt-6-astra-max], forced max reports "2 incompatible combo target(s) will be skipped", both of them Astra.
• Single target: a single cx/gpt-6-astra target is reported unsupported, so applyDecision() in src/sse/handlers/reasoningRouting.ts rejects the request with 400 "Reasoning effort 'max' is not supported by the configured target". The executor serves Astra at both tiers.
• Suffixes: cx/gpt-6-astra-max and cx/gpt-6-astra-ultra are not read as max / ultra requests. extractReasoningIntent() keeps the suffix in the model id and returns no effort, so a rule that matches on source effort max never matches them.
• Editor: the rules editor hides max / ultra for GPT-6 Astra targets and shows the "unsupported" warning.

The review of #14677 found this gap. That PR adds gpt-6-sol (max and ultra) and gpt-6-luna (max only) to the same alias sets, and the regex would miss them too.

Changes

• New src/shared/reasoning/codexExtendedEffort.ts reads the alias sets and exports two helpers:

  • isCodexExtendedEffortBaseModel(model, effort) matches only the exact base model, as the old ^gpt-5\.6-(?:sol|terra|luna)$ did. The suffix parser in policy.ts uses it.
  • codexModelFamilySupportsExtendedEffort(model, effort) also accepts <base>-<suffix> variants, as the old (?:-|$) regexes did. The capability gate in policy.ts and the rules editor use it.

  Both accept an optional codex/ or cx/ prefix and ignore case. The module lives in src/shared so that the client component does not import from open-sse/executors directly.

• policy.ts and ReasoningRoutingRules.tsx call these helpers instead of their regex copies. The gate order in capabilityFor() is unchanged: static registry vocabulary, then declared efforts, then the operator override, and only then this fallback.

• reasoningSuffix.ts itself is not touched, so this PR does not conflict with feat(sse): add GPT-6 Sol and Luna to the Codex catalog #14677. Once both are merged, Sol and Luna are covered here without another edit.

For GPT-5.6 models, every input the old regexes accepted or rejected gives the same result. The only difference is that the gate now also trims whitespace; the editor already did. The models whose result changes are the alias-set members the regex did not name (today: gpt-6-astra).

Out of scope:

• The editor's extendedUnsupportedWarning text still says "suitable Codex GPT-5.6 models". Rewording it changes an English value, and check-ui-value-drift would then require every locale to be updated, so that is better done in a translation pass.
• Once feat(sse): add GPT-6 Sol and Luna to the Codex catalog #14677 lands, getCodexAliasEffortCap() in reasoningSuffix.ts and this module both read the same sets. They could be merged in a follow-up.

Tests

• New tests/unit/reasoning-routing-codex-extended-effort.test.ts (8 tests) covers:

  • forced max keeps Astra (the base id and a variant) in a combo;
  • forced ultra keeps Astra and still drops the max-only gpt-5.6-luna;
  • a single cx/gpt-6-astra target is supported for forced max and ultra;
  • every member of both alias sets passes the gate for its tiers, and the max-only members fail for ultra;
  • -max / -ultra suffix parsing for Astra and for every set member;
  • exact base-model matching (cx/gpt-6-astra-high-max and cx/gpt-6-astral-max are not split) and the helper edge cases.

  The combo and single-target cases use real rules and combos through resolveReasoningRoutingRule(). Six of the eight fail on the base commit; the two that pass there guard the exact-match behaviour. The tests iterate the sets, so new members are covered automatically.

• On a local merge of this branch with feat(sse): add GPT-6 Sol and Luna to the Codex catalog #14677, the same tests pass. In that merge:

  • forced max keeps cx/gpt-6-sol and cx/gpt-6-luna;
  • forced ultra drops only cx/gpt-6-luna;
  • cx/gpt-6-sol-max is read as max.

• Neighbouring tests all pass:

  • reasoning-routing (its comments now name the alias-set fallback instead of the old regex), reasoning-routing-decision-guards, reasoning-routing-api, codex-reasoning-suffix, codex-astra;
  • integration reasoning-routing-pipeline and reasoning-routing-reliability;
  • the rules editor UI test tests/unit/ui/api-key-routing-editor.test.tsx;
  • client-bundle-no-server-only-10692.

• npm run test:vitest:ui: 2427 passed. The 18 failures come from suites that fail to load because vite cannot bundle node:sqlite / node:test (MCP server, autoCombo, memory, TLS clients, ComboSortSelect). None of them imports a file this PR changes.

• ESLint (with suppressions), Prettier, check:cycles and check:file-size are clean.

• typecheck:core reports only the pre-existing TS2322 in src/lib/services/cliproxyAccountHealth.ts:157, which is unchanged from the base. check:dashboard-typecheck reports only the pre-existing TS2698 in src/lib/combos/intelligentRouting.ts, which reproduces with this change reverted.

⚠️ base-red inherited: #14547

[diegosouzapw]

Thanks @QuangBlue — nice cleanup. Reading the max/ultra models from the executor's alias sets removes the drift that made Astra targets get skipped/400ed under forced max/ultra, and the shared helper keeps the rules editor honest too. The diff looks good to me; I could not run the tests locally in this pass, so I'm relying on CI for the two reasoning-routing suites.