nx_ws_client_gate.nx

nx_ws_client_gate.nx -- THE GATE FOR THE RFC 6455 CLIENT HALF, 2026-09-03. SUBJECT: nx_ws_build_frame_masked / nx_ws_parse_frame_server / nx_ws_verify_accept in-process, AND their interoperation with the incumbent nx_websocket.nx. THE TOOTH THAT CARRIES THE CLAIM IS T2, AND IT NEEDS NO FIXTURE OF MINE. A frame built by the new CLIENT builder is handed to the estate's EXISTING SERVER PARSER, untouched, and must come back byte-for-byte. That is real interop against code I did not write and cannot bend: if my masking were wrong in any bit, the incumbent's unmask would produce different bytes and the tooth would fail. T5 IS THE REGRESSION GUARD. The incumbent must still REFUSE an unmasked frame exactly as before. This file is a sibling, not a widening, and the video /signal lane depends on that rule holding. Teeth, in order: T1 a masked frame sets the MASK bit and does NOT leave the payload in clear. T2 INTEROP: client builder -> INCUMBENT server parser recovers the payload byte-for-byte. T3 the reverse direction: incumbent unmasked builder -> new client parser recovers the payload. T4 NEG-CONTROL: the client parser REFUSES a masked frame (a server must not mask). T5 REGRESSION: the incumbent parser still REFUSES an unmasked frame -- unchanged by this file. T6 a payload crossing the 126-byte boundary round-trips (the extended-length path, not just the short). T7 NEG-CONTROL: an undersized output buffer REFUSES instead of writing past it. T8 accept-key verification MATCHES for the key we sent, composing the incumbent's derivation. T9 NEG-CONTROL: a wrong accept value FAILS verification -- without this, T8 could pass on a stub. MEASURED 9/9 GREEN 2026-09-03: 39-byte masked frame round-tripped through the incumbent parser (opcode 1, 33 payload), 308-byte extended-length frame likewise, both refusals firing at -5, buffer refusal at -3. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0