[BUG] Desktop + 3P gateway: Fable 5 1M selection is normalized to bare model id on save — new sessions silently fall back to the 200K row

Environment

• Claude Desktop 1.17377.2 (bundled CLI 2.1.197), macOS 15 (Darwin 25.3)
• 3P LLM gateway config (inferenceProvider: "gateway"), model discovery disabled
• Gateway /v1/models returns claude-fable-5; direct requests with model=claude-fable-5 return 200

Config (configLibrary/<uuid>.json)

{
  "inferenceGatewayBaseUrl": "https://gateway.internal.example",
  "modelDiscoveryEnabled": false,
  "inferenceModels": [
    { "name": "claude-fable-5", "labelOverride": "Fable 5", "supports1m": true,
      "anthropicFamilyTier": "fable", "isFamilyDefault": true }
  ]
}

Steps to reproduce

1. Configure a 3P gateway with claude-fable-5 + supports1m: true as above. The picker correctly shows two rows: "Fable 5" (200K) and "Fable 5 1M".
2. In the Code tab model picker, select Fable 5 1M. The active session works with the 1M window.
3. Start a new session (or switch models once and come back).

Expected: new sessions use the previously selected "Fable 5 1M".
Actual: new sessions land on the bare "Fable 5" row with a 200K context budget. The user has to manually re-select "Fable 5 1M" for every session.

Root cause (from local inspection)

Two behaviors compose into the regression:

1. The renderer strips [1m] when persisting the model selection. The setModel path normalizes the id before writing __model_selector_state (per-surface sticky state in cowork_account_settings.json), so claude-fable-5[1m] is stored as bare claude-fable-5. This matches the intentional CLI v2.1.173 change ("Fable 5 includes 1M context by default, so the suffix is now stripped automatically") — harmless on the first-party API where bare Fable 5 is 1M.
2. Behind a 3P gateway, the bare Fable row is budgeted at 200K. The main-process selector config generation always emits two rows for supports1m: true models (bare + [1m] variant), and the bare claude-fable-5 row is not special-cased as natively-1M. On restore, the stored bare id resolves to the bare row.

So: select 1M → persisted as bare → next session resolves to the 200K row. The stored selection can never durably stay on 1M.

Verified stored state after selecting "Fable 5 1M":

"__model_selector_state": { "code": { "model": "claude-fable-5" } }

Suggested fix (any one of these)

• Treat bare claude-fable-5 (and other natively-1M models) as 1M in gateway model rows — i.e. don't emit a 200K bare row for models whose 1M window is the API default; or
• Skip the [1m] normalization when persisting selections for gateway configs where a distinct [1m] row exists; or
• On restore, upgrade a stored bare id to its [1m] variant when the bare row was created from a supports1m expansion.

Workaround

Manually editing __model_selector_state.code.model back to claude-fable-5[1m] in cowork_account_settings.json restores the 1M default — until the next model switch re-strips it.