Cowork cloud egress: WebSocket (wss) hosts refused while ordinary HTTPS to the same service is allowed

**Surface:** Claude Cowork on the web, cloud sessions, Max plan (individual).
**Setting:** Settings > Capabilities > Allow network egress ON, Domain allowlist = All domains, unchanged.

Since the 10 Sep egress regression on this account (#34690) was partially restored on 14 Sep, ordinary HTTPS works again but **WebSocket endpoints are still refused by the gateway**, including for a service whose HTTPS API is allowed in the same session.

Measured 2026-09-14, 17:2x UTC, one session:

```
https://api.browserbase.com/ 404 (reaches the origin, allowed)
wss://connect.usw2.browserbase.com/ 403 Host not in allowlist: connect.usw2.browserbase.com.
Add this host to your network egress settings to allow access.
```

The Playwright form of the same failure:

```
BrowserType.connect_over_cdp: WebSocket error: wss://connect.usw2.browserbase.com/ 403 Forbidden
- ... 403 Forbidden
- WebSocket was closed before the connection was established
```

**Expected:** with the allowlist set to All domains, a wss host is reachable like any other.

**Actual:** the gateway answers 403 with "Host not in allowlist", naming a host the account's setting does not exclude, while plain HTTPS to arbitrary hosts (www.google.com, example.com, api.openai.com, cdn.jsdelivr.net) succeeds from the same session.

**Impact:** any browser-automation or realtime service driven from a cloud session is dead, because the control channel is a WebSocket even when the REST API is reachable. Sessions can create a remote browser and then cannot attach to it.

**Related, same account, same window:** `pypi.org` and `registry.npmjs.org` return 403 from that session while arbitrary web hosts succeed, which inverts the usual symptom and breaks `pip install` in a cloud session. Details on #34690 (comment 5667492876).