docs: ws-byte-adapter POC complete (GO) — resolve OQ-01, update framing facts

POC at /workspace/ws-byte-adapter-poc/ (not on main), all tests green:
- call round-trip over axum WS ↔ adapter ↔ ChannelsAdapter ↔ channel-0
  Dispatcher (published alkcall API only, no forks)
- 3 MiB payload splits across 1 MiB WS messages, byte-intact reassembly
- 20 interleaved calls reassemble without corruption/cross-correlation

Findings merged:
- OQ-01 resolved: byte-stream both directions, bounded mpsc (64 slots)
  inbound, outbound chunk-header parsing (frame-as-two-chunks
  live-confirmed), 1 MiB message cap with split, flush no-op, close →
  EOF → REQ-CH-02
- websocket.md: chunk ≠ frame on channel 0 (frame reassembly required);
  operationId is the request payload key
- task ws-byte-adapter → completed with full Summary; ws-upgrade-session
  unblocks

docs/architecture/websocket.md

@@ -123,7 +123,13 @@ WS binary message (message boundary = transport frame)
 - **Channel 0's payload is the call protocol's frame format**
   (alkcall ADR-014): a 4-byte big-endian length prefix + UTF-8 JSON
   `EventEnvelope`. This is exactly the framing channel 0 uses over
-  TCP+TLS; the WS path is not special at this layer.
+  TCP+TLS; the WS path is not special at this layer. **Chunk ≠ frame**:
+  a single frame may arrive as multiple chunks (the frame writer
+  issues prefix and body as separate writes through the mux —
+  live-confirmed in the ws-byte-adapter POC), so channel-0 consumers
+  MUST reassemble length-prefixed frames from the channel-0 byte
+  stream, never parse per-chunk. The request payload's operation name
+  key is `operationId`.
 - **Data-channel payloads are opaque** — the handler owns its framing
   (alkcall ADR-035: no `stream_type` anywhere in the channels layer).
 - **Text WS messages are rejected** with a protocol-level close (code