Effort picker shows a level as selected while requests are silently applied at a lower level, with no warning

**Environment:** VS Code extension v2.1.241 (reproduced across a session that also survived a window reload), macOS, Claude Sonnet 5, Pro/Max-class plan.

**What happened:** The effort picker (Shift+Tab menu / mode indicator) showed "Extra high" (`xhigh`) as the selected effort, with the slider fully right and no error or warning shown anywhere in the UI. Despite this, every completed turn was actually being processed at `high`, not `xhigh` — confirmed directly from the session transcript's `effort` field on the `assistant` message entries (not inferred from the UI), across many consecutive turns over roughly an hour, with no single turn actually landing at `xhigh` during that window.

**Evidence** (from the session transcript, `~/.claude/projects//.jsonl`, `effort` field on `assistant`-type entries):
```
effort: high | 2026-08-23T21:51:35.051Z
effort: high | 2026-08-23T21:51:35.477Z
effort: high | 2026-08-23T21:51:39.695Z
effort: high | 2026-08-23T21:52:12.181Z
```
All from a session where the picker displayed "Extra high" selected the entire time. No corrective action was taken between these turns other than normal conversation.

**Fix found:** Explicitly re-opening the effort picker and re-selecting "Extra high" — even though it already appeared selected — caused the very next turns to correctly show `effort: xhigh`:
```
effort: xhigh | 2026-08-23T21:53:52.214Z
effort: xhigh | 2026-08-23T21:53:55.633Z
```

**Expected:** Either the picker should never show a level as selected when it isn't actually being applied, or — matching the existing behavior for org-level effort caps ("a warning names the requested and applied levels") — a visible warning should surface when a requested effort silently downgrades.

**Actual:** Silent, sustained desync between displayed and applied state, invisible without directly inspecting the session transcript. Re-selecting the already-selected value is what resolves it, which is a confusing, undiscoverable fix.

**Note:** I don't have a minimal repro for how the session entered this state — it may be related to the session having started, then a later `settings.json` change to the default effort level (`effortLevel`), then a VS Code window reload. Happy to provide the full session transcript privately if useful.

Start by reproducing the effort picker state across a settings.json change and VS Code window reload, then compare the picker value with the effort field in ~/.claude/projects//.jsonl. Check the existing org-level effort-cap warning behavior as a reference. Done means the displayed and applied levels remain synchronized, or a visible warning identifies the requested and applied levels when they differ.

Written by the indexing model from the issue text.