Desktop app shows/selects non-1M Opus 4.8 for a session the CLI reports as 1M

Summary: For the same Claude Code session, the CLI and desktop app disagree on the selected model. The CLI holds "Opus 4.8 (1M context)"; the desktop app has plain "Opus 4.8" (non-1M) selected, and a desktop-shared session drifts from 1M back to non-1M over time.

Repro (same Session ID, two surfaces):

• CLI /model → "Opus 4.8 (1M context) (default)"
• CLI /status → Model: "Opus 4.8 with 1M context"
• Desktop app /model picker → plain "Opus 4.8" selected (✓); "Opus 4.8 (1M context)" present but unchecked

Rules out entitlement: 1M is offered in the desktop picker, /status confirms 1M, and flags are healthy (hasExtraUsageEnabled: true, cachedExtraUsageDisabledReason: null, CLAUDE_CODE_DISABLE_1M_CONTEXT unset). This appears to be a desktop-client model-selection sync bug, not a plan/access problem.

Open concern: Unclear whether messages composed from the desktop app (while showing non-1M) are served at 200k or merely mislabeled. If the former, it's a real capability downgrade.

Expected: A session set to 1M in the CLI shows and stays 1M when driven by the desktop app.
Actual: Desktop selects non-1M and drifts back; CLI and desktop disagree for the same session.

Possibly related: #29929, #39970, #54320
Environment: Claude Code 2.1.168, Linux, Max 20x. Desktop app remote-controlling a CLI session. (Screenshots to follow.)