Statusline/model picker shows base model (missing "1M context") on session resume until model picker is reopened

Description

When resuming a session that was previously running on the 1M-context beta variant of a model (e.g. Opus with [1m]), the CLI resumes the correct model family but does not show or apparently apply the 1M-context variant until the model picker is manually reopened and the model reselected. After reselecting (even selecting the same model that's already "active"), the statusline and presumably the actual context window correctly reflect the 1M variant.

Steps to reproduce

1. Run a session on an Opus (or other) model with the 1M-context beta enabled (claude-opus-4-8[1m]).
2. End the terminal / process.
3. Resume the session later (claude -c, claude -r <id>, or the CLI's own auto-continue prompt) from a fresh process.
4. Observe the statusline (via the statusLine hook / hookSpecificOutput.model.display_name field passed to the status line script): it shows the base model (e.g. "Opus") with no (1M context) suffix, and model.id has no [1m] suffix.
5. Open the in-app model picker and reselect the same model (still showing/selecting the 1M option).
6. Statusline immediately updates to show (1M context) / model.id gains the [1m] suffix.

Expected behavior

On resume, the CLI should restore (or immediately re-verify) the same model variant, including 1M-context status, that the session was using when last active — without requiring a manual picker round-trip.

Investigation notes

• Confirmed via a custom statusline script that only passes through input.model.display_name/input.model.id verbatim — no local logic decides the 1M suffix, so the wrong value is coming from the CLI itself in the hook payload.
• ~/.claude.json contains a clientDataCacheSlots map with timestamped model fields, some recorded as claude-opus-4-8 (no [1m]) and others as claude-opus-4-8[1m], entrypoint "cli" in both cases.
• ~/.claude.json also has an additionalModelOptionsCache array that appears to track which models currently have the 1M option unlocked/available — it currently holds only one stale entry, suggesting this cache is populated/refreshed lazily (e.g. only when the model picker is opened) rather than on session start/resume.
• Working theory: on resume, the CLI doesn't re-run whatever entitlement/availability check populates the 1M-availability cache, so it falls back to displaying/using the base model until the picker forces that check.

Environment

• Claude Code version: 2.1.217
• OS: Windows 11 Pro (10.0.26200)
• Resume methods tried: bare claude auto-continue, claude -c, claude -r <session-id> — same symptom on all