New chats remain stuck in Agent Host after switching back to Local Chat due to persisted chat.userSelectedSessionType

### Problem

After Agent Host / Copilot CLI has been selected once, VS Code can persist:

```text
chat.userSelectedSessionType = agent-host-copilotcli
```

in:

```text
User/globalStorage/state.vscdb
```

After changing the chat configuration back to Local / Extension Host and fully restarting VS Code, newly created Agent chats still open as Agent Host sessions.

Third-party language models remain correctly registered and visible in normal Chat / Manage Models:

```text
availableModels="unify-chat-provider/...many models...,copilot/auto"
```

But each newly created Agent chat is still routed to:

```text
sessionKey="agent-host-copilotcli"
modelTarget="agent-host-copilotcli"
availableModels="agent-host-copilotcli:auto"
```

So the user can change the relevant Local / Agent Host settings, restart VS Code, and still be effectively trapped in the previously selected Agent Host session type for new chats.

### Steps to reproduce

1. Use Agent Host / Copilot CLI so that VS Code persists `chat.userSelectedSessionType=agent-host-copilotcli`.
2. Change the chat configuration back to prefer / enable the Local / Extension Host path.
3. Fully restart VS Code.
4. Create a new Agent chat.
5. Observe that the new session is still created as `agent-host-copilotcli`.

### Expected behavior

Changing the harness configuration back to Local / Extension Host should affect newly created chats after restart.

The user should be able to leave Agent Host through supported settings / UI without manually editing VS Code's internal state database.

### Actual behavior

The persisted `chat.userSelectedSessionType` continues to win, so new chats remain on `agent-host-copilotcli` even after explicitly switching the relevant settings back to Local.

For example, the behavior persisted with:

```json
"chat.editor.preferCopilotHarness": false,
"chat.defaultToCopilotHarness": false,
"chat.editor.localAgent.enabled": true,
"chat.editor.copilotCli.hideExtensionHost": false
```

### Investigation

I found the persisted value in `User/globalStorage/state.vscdb`.

Looking at the VS Code 1.134 workbench code, `chat.userSelectedSessionType` is considered before the default harness selection. This matches the observed behavior: while the persisted entry exists, it overrides the explicit Local harness configuration for new chats.

The strongest confirmation is that removing only this persisted entry changes the routing immediately after restart.

### Workaround

With VS Code fully closed, remove only:

```text
chat.userSelectedSessionType
```

from `User/globalStorage/state.vscdb`.

Before:

```text
chat.userSelectedSessionType = agent-host-copilotcli
```

After removing that single state entry and restarting VS Code:

```text
sessionKey=undefined
modelTarget=undefined
availableModels="unify-chat-provider/..."
```

New chats return to the Local / Extension Host path and the third-party models become selectable again.

### Environment

- VS Code: `1.134.0`
- OS: Windows 11 + Remote WSL2 (Ubuntu)

### Scope

This report is about VS Code's built-in chat session routing / persisted session-type state. A third-party language model provider made the symptom visible, but the persisted routing behavior itself is in VS Code core.

There also appears to be a separate Agent Host BYOK bridge issue where third-party models work in Local Chat but Agent Host exposes only `Auto`; that is already being discussed in #326344.

This issue is specifically about the persisted session-type selection preventing the user from returning to Local Chat even after changing the relevant configuration.