🤖 fix: VS Code webview does not load app/providers config (thinking floors, model list)

[ThomasK33]

Problem

The VS Code webview never connects the app-config and providers-config stores (AppConfigStore, ProvidersConfigStore). The desktop app connects them in AppLoader (getProvidersConfigStore().setClient(api)); the webview does not. This has two visible effects:

• Wrong thinking display. The selector shows the level raised to the model's built-in minimum (for example MED), not to the user's configured per-model minimum, so it can differ from the level the turn actually uses. The backend applies the configured minimum.
• Empty model list. The composer's model list and model cycling have nothing to choose from; only the current model is shown.

Split out of #4755. PR #4765 fixed the settings overwrite there and deliberately stopped clamping the thinking level in the webview, because clamping with built-in floors raised turns above lower floors the user had configured.

Proposed fix

Connect these stores to the webview's bridge client. Before that, check which oRPC paths they call; for example the providers store uses providers.getConfig/onConfigChanged, which are allowed, and the app-config store's calls may not be. Allowlist only read paths that can be justified.

Refs #4755

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $26.99

[linear-code]

MUX-288

[ThomasK33]

Note from #4778 review: once models become selectable here, the webview composer's onModelChange must also update the active agent's per-agent cache (getWorkspaceAISettingsByAgentKey), as the desktop composer does. Otherwise the newly mounted WorkspaceModeAISync restores the old seeded model when the user switches agents and back.

[ThomasK33]

Correction: the issue body says the webview's model list is empty. It is not. With no providers config loaded, computeSelectableModels keeps every suggested model visible, so the list is unfiltered rather than empty. The thinking-floor part of this issue stands. The per-agent-cache note I added here is being fixed separately as a follow-up to #4778.

[ThomasK33]

Picked up by the VS Code webview follow-up workspace (workspace-23, branch fix/vscode-webview-load-config). A safe projection looks feasible in a small PR:

1. providers.getConfig/onConfigChanged are already allowed. The response carries no keys (only apiKeySet-style booleans), but it has baseUrl, baseUrlResolved, deploymentUrl and apiKeyFile, which the webview does not read. The extension host will strip them, the way 🤖 fix: allow read-only admin policy in the VS Code webview, redacting gateway URLs #4807 strips forcedBaseUrl.
2. config.getConfig/config.onConfigChanged will be allowed, with the getConfig result projected in the extension host to the three fields AppConfigStore reads (routePriority, routeOverrides, minThinkingLevelByModel). Everything else (prompts, governor URL, preferences, task settings) stays in the host. onConfigChanged carries empty signals only. All other config.* procedures stay blocked.
3. The webview connects both stores to its bridge client while the connection is in API mode, and reconnects them on recovery.

If review shows the projection is not enough, I will park this instead. PR to follow.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $4.48