Bug: Public WebSocket RPC endpoints returning 405 / 403 after April 21 maintenance

Path: /base-chain/api-reference/rpc-overview

**Summary**
All four public Base WebSocket endpoints are rejecting connections since the April 21 RPC migration (incident kd90bdz37xw5). WebSocket handshakes never reach the backend — they are being blocked at the Cloudflare layer.

**Affected endpoints**
- wss://mainnet.base.org
- wss://mainnet-preconf.base.org
- wss://sepolia.base.org
- wss://sepolia-preconf.base.org

**Reproduction**
Reproduced independently using wscat from a MacBook on a residential/client IP:
```
$ wscat -c wss://mainnet.base.org
error: Unexpected server response: 405
```

Also confirmed via curl with a full RFC 6455-compliant WebSocket upgrade request (GET + Upgrade: websocket + Sec-WebSocket-Key headers) — all four endpoints return 405.

Additional testing from a server/datacenter IP returns:
```
HTTP/2 403
x-deny-reason: host_not_allowed
```

**Root cause hypothesis**
Per RFC 6455 §4.1, the WebSocket opening handshake must be an HTTP GET request. The 405 response is being returned before the JSON-RPC layer is reached and before a WebSocket connection is established. The `x-deny-reason: host_not_allowed` header on the 403 variant points to a Cloudflare proxy misconfiguration — WebSocket upgrade passthrough appears to have been dropped during the April 21 node migration.

HTTP RPC (POST) requests to https://mainnet.base.org are unaffected.

**Impact**
- eth_subscribe is completely unavailable on all public endpoints
- The WebSocket code examples in the official docs (e.g. newFlashblocks) are non-functional
- Users are being silently broken with no changelog or deprecation notice

**Expected behavior**
WebSocket connections should complete the upgrade handshake and return HTTP 101 Switching Protocols.

**Request**
Please either restore WebSocket support on the public endpoints or update the docs to reflect that these endpoints are HTTP-only, so users can plan accordingly.