fix(gateway): drop WebChat frames for closed sockets

[cursor]

Bug and impact

WebChat replies for a connection that already closed stayed on the process-wide outgoing queue. ws_dequeue_outgoing only runs for a live socket, so those frames were never removed. After 64 such replies (MAX_QUEUE), ws_send_to failed for every client, including ones still connected. Dashboard WebChat then delivered nothing until the process restarted.

Concrete trigger: a client sends a prompt and disconnects (refresh, dropped network) before the reply is written. Each lost reply occupies one queue slot forever. A long-running edge process hits the cap through ordinary reconnects.

Root cause

ws_send_to enqueued the frame before checking that a socket was registered, and returned success when wsi was NULL. ws_unregister_conn cleared the connection table entry but left that conn_id's frames on the shared list.

Fix

• On unregister, drop outgoing frames for that conn_id.
• If no live socket is registered, free the frame and do not enqueue. The return stays 0, matching the existing contract for a well-formed session id with no socket.

Validation

make test_ws then ./build/test_ws.

New cases cover a frame queued before close (spliced out of the middle of the list, with a sibling connection left intact) and 128 sends to a conn_id that was never registered. Both must leave room for a live client. Existing WebSocket queue tests still pass.

  

[adriannoes]

Superseded by #119: consolidated into the operator-authored branch fix/gateway-ws-frames (same fix, re-validated with make test_ws, CI=true make test, make static). Closing in favor of the consolidation.