Agent Host sandbox toggle uses client OS instead of remote host OS

## Type of issue

Bug

## Reproduction

1. Use a macOS VS Code client connected to an Agent Host running on Windows.
2. Open a Copilot Agent Host session using the SDK built-in PowerShell tool.
3. Observe that the permissions UI does not indicate that sandboxing is enabled for the Windows host.
4. Run a PowerShell command that needs sandbox bypass.

## Actual behavior

The session prompts:

> Run in terminal outside the sandbox?

After approval, the tool fails with:

> GenericFailure: Sandboxing is enabled but not supported on this platform: Windows sandboxing requires BaseContainer. Update Windows to a supported version: https://aka.ms/ghcp-sandbox-os-support

This also happens with the session permission level set to **Allow all**, because sandbox bypass is intentionally treated as privilege elevation.

Agent Host logs show:

- the SDK sandbox configuration was applied via `session.options.update`
- `sdkMode=allow-all`
- the PowerShell request still required confirmation as a sandbox-bypass request
- managed settings contained `remoteControl,permissions`, with `failClosed=false`; sandboxing did not appear to be enforced by managed policy

## Expected behavior

The permissions picker should reflect the effective sandbox state of the target Agent Host. A macOS client connected to a Windows Agent Host should display and update the Windows sandbox setting used by that host.

If Windows sandbox support is unavailable, an experiment/default should not silently enable it and leave the session unable to execute terminal commands.

## Suspected cause

The client-side picker resolves the setting using the renderer's local platform:

https://github.com/microsoft/vscode/blob/main/src/vs/platform/agentHost/common/agentService.ts#L295-L297

`getAgentHostCopilotSandboxSettingId(..., windows = isWindows)` therefore selects the macOS/Linux setting on a macOS client, even when the connected Agent Host runs on Windows.

Meanwhile, `AgentHostSandboxForwarder` forwards all sandbox settings to every connected Agent Host, and the Windows host consumes `chat.agent.sandbox.enabledWindows`:

https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/terminalContrib/chatAgentTools/browser/agentHostSandboxForwarder.ts

This allows the UI to read `chat.agent.sandbox.enabled` while the target host executes with `chat.agent.sandbox.enabledWindows`. The Windows setting is also experiment-controlled with `mode: auto`, so it may be enabled without a deliberate user edit.

Session-specific sandbox settings added in #335364 make the effective target state especially important to surface accurately.

## Suggested fix

Derive the toggle from the target Agent Host platform and effective root/session sandbox configuration rather than the local renderer OS. Prefer having the Agent Host report its effective sandbox state so the picker cannot diverge from what is sent to the SDK.

It would also help to log the applied sandbox `enabled` state and target platform (without filesystem policy details) when calling `session.options.update`.

## Workaround

Explicitly set:

```json
"chat.agent.sandbox.enabledWindows": "off"
```