Integrated Browser: Chrome DevTools remote-debugging frontend fails with `(blocked:origin)` / "Unsafe attempt to load URL ... from frame with URL chrome-error://chromewebdata/" when not using Remote-SSH/WSL port forwarding

Type: Bug

Integrated Browser: Chrome DevTools remote-debugging frontend fails with `(blocked:origin)` / "Unsafe attempt to load URL ... from frame with URL chrome-error://chromewebdata/" when not using Remote-SSH/WSL port forwarding

## Description

When connecting the Integrated Browser to a remote Chromium DevTools instance (e.g. `QTWEBENGINE_REMOTE_DEBUGGING`, or any `--remote-debugging-port` target) tunneled to `127.0.0.1:` via a plain SSH port forward, navigating to the public DevTools frontend URL (`https://chrome-devtools-frontend.appspot.com/.../inspector.html?ws=127.0.0.1:/devtools/page/`) fails.

The integrated-borwser-DevTools network panel shows the `inspector.html` request itself with status `(blocked:origin)`, and the console reports:

```
Unsafe attempt to load URL https://chrome-devtools-frontend.appspot.com/serve_rev/@/inspector.html?ws=127.0.0.1:/devtools/page/ from frame with URL chrome-error://chromewebdata/. Domains, protocols and ports must match.
```

This is caused by Chromium's Private Network Access (PNA) policy: `chrome-devtools-frontend.appspot.com` is a public HTTPS origin, and PNA blocks a public origin from silently reaching a private/loopback address (`127.0.0.1:`) unless the target answers the CORS preflight with `Access-Control-Allow-Private-Network: true` - which a raw `--remote-debugging-port` listener never does.

**Interesting behavior:** the exact same flow (same DevTools frontend URL, same forwarded port) works fine in the Integrated Browser when the workspace is opened via **Remote-SSH** or **Remote-WSL** with VS Code's own automatic port forwarding. It only fails when the port is reachable via a manually created SSH tunnel (`ssh -L :localhost: ...`) in a local (non-remote) window. This suggests VS Code's built-in port-forwarding proxy adds headers/behavior that satisfies the PNA preflight, while a plain forwarded TCP socket does not.

Confirmed working: opening the identical `127.0.0.1:` URL in a standalone desktop Chrome window works without any issue, in both local and remote setups - the problem is specific to the Integrated Browser's embedded webview.

## Steps to reproduce

Error case:

1. Start a process with Chromium remote debugging enabled, e.g. `--remote-debugging-port=9222`, on a remote host.
2. From a local (non-Remote-SSH, non-Remote-WSL) VS Code window, manually forward the port with a plain SSH tunnel: `ssh -L 9222:localhost:9222 user@remotehost -N`.
3. `curl http://127.0.0.1:9222/json/list` to confirm the tunnel works and get a `devtoolsFrontendUrl`.
4. Open that `devtoolsFrontendUrl` in the Integrated Browser (`Simple Browser: Show` / `View: Open Integrated Browser`).

Success case:
1. Open a remote workspace (ssh/WSL)
2. Start a process with Chromium remote debugging enabled, e.g. `--remote-debugging-port=9222`, on the remote host.
3. From the remote VS Code window, manually forward the port with a plain SSH tunnel: `ssh -L 9222:localhost:9222 user@remotehost -N`.
4. `curl http://127.0.0.1:9222/json/list` to confirm the tunnel works and get a `devtoolsFrontendUrl`.
5. Open that `devtoolsFrontendUrl` in the Integrated Browser (`Simple Browser: Show` / `View: Open Integrated Browser`).

## Expected

The DevTools frontend loads and connects, as it does when the identical URL is opened in a standalone desktop browser, or in the Integrated Browser under Remote-SSH/Remote-WSL.

## Environment

VS Code version: Code 1.135.0 (08d4889f9ec4a1685d257b9b95de036c8e1ce1e5, 2026-08-25T14:26:52Z)
OS: Ubuntu 24.04