fix(models): keep distinct codex models out of effort-variant families

[Neonforge98]

Problem

groupModels labels every gpt-<version>-codex-* id as the "GPT Codex" family. A distinct model such as gpt-5.3-codex-spark therefore lands in the effort-variant group, whose only in-group control is the reasoning-level pill (low/medium/high/xhigh). The model cannot be selected anywhere in the picker. For ChatGPT-login Codex accounts this is the only model the provider accepts (gpt-5.3-codex is rejected with "not supported when using Codex with a ChatGPT account"), so those users cannot pick a working model.

Solution

In parseModelGroup, tokens that follow a matched GPT tier and are not variant suffixes (low, medium, high, xhigh, fast, thinking, …) stay in the family label. gpt-5.3-codex-spark becomes its own "GPT 5.3 Codex Spark" row while gpt-5.3-codex, gpt-5.3-codex-medium and gpt-5.6-sol-xhigh-fast keep their current families. isModelVariantSuffixToken is exported from modelVariants so both modules share one suffix table.

Potential risks

• Any provider id with a tier followed by a non-suffix token now forms its own family instead of merging into the tier family. Tierless ids (gpt-4-turbo → "GPT 4") are untouched.
• The Rust launch mapping already passes unknown suffixes through as the model id (gpt-5.3-codex-spark is sent verbatim with no effort override), so the wire request is unchanged.

Verification

• New regression test in modelGrouping.test.ts covering the spark row next to the 5.3 family and a 5.6 variant id.
• pnpm typecheck, eslint --max-warnings 0, prettier, and vitest --changed on the touched tree: 617 files / 4898 tests passed.
• Reproduced live: with the old grouping the E2E picker selected gpt-5.3-codex-medium when asked for spark; with this change the spark row is selected and the Codex thread resumes on gpt-5.3-codex-spark.