Consider disabling WebSocket message splitting when permessage-deflate is off

## WebSocket message splitting adds significant latency for large files on proxied connections

When serving code-server behind a proxy (which is the common production deployment), the 256KB WebSocket message splitting introduced in [microsoft/vscode#174278](https://github.com/microsoft/vscode/pull/174278) multiplies per-message RTT overhead significantly for large file operations like image previews.

### Background

VS Code splits large IPC messages into 256KB chunks (`MaxWebSocketMessageLength = 256 * 1024` in `ipc.net.ts`) to avoid blocking the Node.js event loop during zlib compression. Each chunk becomes a separate WebSocket message.

### The latency problem in proxied deployments

In a proxied deployment (e.g. a gateway in front of a devbox), each WebSocket message incurs a full round-trip. With 100ms RTT between the proxy and the devbox:

- A 10MB file generates ~40 chunks (10MB ÷ 256KB)
- Each chunk = one WebSocket message = one round-trip
- Total overhead: ~40 × 100ms = **~4 seconds of pure latency**

We tested image preview times (time from opening a file in the explorer to the image fully rendering) across different file sizes at 100ms simulated RTT:

| File size | Splitting ON | Splitting OFF | Improvement |
|-----------|-------------|--------------|-------------|
| 145 KB | 2,212ms | 2,251ms | ~0% |
| 1 MB | 1,988ms | 1,707ms | 14% |
| 1.5 MB | 2,093ms | 1,412ms | 33% |
| 5.6 MB | 4,255ms | 2,193ms | 48% |
| **10.3 MB** | **7,262ms** | **2,888ms** | **60%** |

### Is disabling splitting safe? (Does zlib actually block?)

A few basic tests didn't seem to indicate this issue in our case, but more investigation may be needed

### Question

Would you consider making `enableMessageSplitting` configurable via a CLI flag, or defaulting it to `false` for single-user deployments?

Happy to submit a PR if there's agreement on the right approach.