## Why
Large nested-tool callbacks can occupy a WebSocket and delay unrelated session
operations on the same code-mode connection.
## What changed
- Negotiate the optional `dual-websocket-v1` capability and pair a second,
token-scoped WebSocket with the control connection.
- Route nested-tool callbacks and their results over the bulk socket while
keeping session operations, notifications, and execution responses on the
control socket. Reject messages sent on the wrong lane.
- Preserve the single-connection transport when the capability is unavailable,
and bound pairing, queued callbacks, and deferred cross-socket messages.
- Defer callbacks that arrive before their execution-started response, and
return delegate errors without disconnecting the connection.
## Testing
Add protocol, transport, driver, and WebSocket integration coverage for
capability negotiation, lane routing, pairing failures, out-of-order messages,
and progress during large concurrent tool results.
GitOrigin-RevId: fa4504653e7cbf3c4ec930ae57aa0a41345bad66
## What changed
- Add a `--listen` option that accepts `stdio`, `stdio://`, or a
`ws://IP:PORT` endpoint, while retaining stdio as the default.
- Serve the existing length-prefixed protocol in binary WebSocket messages,
with isolated connections, shared host limits, and a `/readyz` endpoint.
- Reject browser-origin handshakes and contain malformed frames to the affected
connection.
## Testing
- Cover listen URL parsing and complete-frame encoding and decoding.
- Exercise readiness, cell execution, tool callbacks, large frames, concurrent
connections, malformed frames, and origin rejection through the WebSocket
listener.
GitOrigin-RevId: 01c8be4c6256b8ce4a3a0002440dcb3294e5f887
