[BUG] VS Code ext: model/effort picker disconnected (both ways) from a session spawned with settings.local.json model/effortLevel overrides

Environment: VS Code Insiders extension 2.1.251 (darwin-arm64), macOS 25.6.0.

Setup: .claude/settings.local.json in the workspace carries "model": "claude-opus-5", "effortLevel": "low"; a new Claude Code tab is then opened via the URI handler (vscode-insiders://anthropic.claude-code/open). (Same behavior observed with other model/effort pairs; the settings values are captured correctly at session init.)

The override itself works — the session's transcript JSONL (~/.claude/projects/<ws>/<sessionId>.jsonl) logs "model":"claude-opus-5","effort":"low" on every assistant message. The bug is that the picker UI is disconnected from that real state in both directions:

1. Read direction: the spawned tab renders no Effort bar at all until the user manually re-selects a model in Switch model.... The picker never displays the session's actual (settings-injected) model/effort.
2. Write direction: after the user manually selects a different pair in the UI (e.g. Opus (1M context) + Effort (Medium), confirmed showing in the actions menu), the running session keeps its init-captured values — the next turn (delivered via cross-session SendMessage) still logs "model":"claude-opus-5","effort":"low". The UI now confidently displays a model and effort the session is not using.

Expected: the picker reflects the session's live model/effort, and a picker change either applies to subsequent turns or is refused visibly.

Impact: for programmatically spawned sessions (settings-file override + URI handler — the documented way to set model/effort per spawn, since the URI carries neither), the UI is not a truthful readout and not a working control; the only reliable readout is grepping the session JSONL for "model"/"effort". A user who "fixes" the effort in the UI reasonably believes it took effect.

Not verified: whether a picker change binds to turns typed into the tab's own input box (our follow-up turns were bridge-delivered via SendMessage). Possibly related: #73742 (daemon-hosted forks pinning --effort from cached session state).

Repro evidence (timestamps UTC): session created 09:44:53Z with the override; turn 1 (09:44:55Z) logs opus-5/low; user sets picker to Opus 1M/Medium; turn 2 (09:49:02Z) still logs opus-5/low while the actions menu shows Opus (1M context) / Effort (Medium).