Docs present local sandbox capabilities (per-host filtering, cross-platform isolation) as working, but they do not — please align docs with actual behavior

### Summary
The documentation and the `/sandbox` settings UI present capabilities as working that do not actually function. Per-host network filtering (`allowedHosts` / `blockedHosts`) is offered as a way to allow/block individual hosts, and the docs claim a "consistent isolation experience" across macOS, Linux, and Windows. In practice these do not hold, so users trust documented features, then waste time discovering they don't work. Please update the documentation to match actual behavior.

### What the docs say
- [Configuring local sandbox settings](https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings) describes host rules as a way to allow or block access to individual hosts when outbound connections are otherwise restricted, with no indication that this may not take effect.
- [About cloud and local sandboxes](https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes) states local sandboxing delivers "a consistent isolation experience regardless of your operating system."

### Actual behavior
Per-host filtering (`allowedHosts` / `blockedHosts`) does not actually restrict traffic to/from individual hosts. This is confirmed in the sandbox backend source ([microsoft/mxc](https://github.com/microsoft/mxc)):

- **macOS (seatbelt backend).** The seatbelt profile builder cannot filter by hostname. When `allowedHosts` is set, it does not restrict to those hosts — it degrades to allowing **all** outbound. Source comment in `src/backends/seatbelt/common/src/profile_builder.rs`: *"Seatbelt only accepts `*` or `localhost` in `(remote ...)` filters — per-hostname filtering isn't possible, so allowedHosts degrades to allow-all outbound as a best-effort."* `blockedHosts` is rejected outright in `seatbelt_runner.rs`: *"macOS Seatbelt does not support per-host network filtering."* So a user who configures `allowedHosts` to limit egress actually gets unrestricted outbound.

- **Linux (bubblewrap backend).** With `allowOutbound: false`, configured host rules are dropped as a no-op. Runtime log (`~/.copilot/logs/process-*.log`): `[rust:sandbox_spawn] allowOutbound is false (no-op without outbound); dropping 1 allowedHosts and 0 blockedHosts.` The allowed host (`api.github.com`) is unreachable — DNS fails (`lookup api.github.com on 127.0.0.53:53: connection refused`).

- **Windows.** Separately, the sandbox fails to start commands at all on current builds (see #3849: `Experimental_CreateProcessInSandbox returned E_NOTIMPL`).

### Impact
Because the docs and UI advertise these features as functional, users rely on them and spend time troubleshooting capabilities that do not work as documented. On macOS this is also a security concern: configuring `allowedHosts` to narrow egress silently results in unrestricted outbound. The gap between documented capability and real behavior is the core problem.

### Request
Please update the documentation to reflect actual behavior:
1. State the real support status / limitations of `allowedHosts` / `blockedHosts` (currently they do not take effect; on macOS `allowedHosts` degrades to allow-all outbound).
2. Stop presenting a "consistent cross-platform isolation experience" while platforms such as Windows cannot run sandboxed commands at all.

### Environment
- Copilot CLI v1.0.64-0
- Per-host filtering behavior verified against microsoft/mxc backend source (macOS seatbelt, Linux bubblewrap); Linux behavior also reproduced at runtime. Windows failure per #3849.

### Related
- #3849 (Windows sandbox `E_NOTIMPL` — sandboxed commands fail to start)

查看“Configuring local sandbox settings”和“About cloud and local sandboxes”页面，然后将其中的描述与引用的 mxc Seatbelt 和 bubblewrap 行为以及相关 issue #3849 进行比较。完成的标准是：文档准确说明当前的主机过滤限制和特定平台的 sandbox 支持情况，包括 Windows 上启动命令失败的问题。

由索引模型根据 Issue 内容生成。