Two subtle race conditions in the browser WebSocket client:
1. Stale-event clobber. When connect() is called while the old socket is
in CLOSING state, the readyState guard falls through and a new socket
is assigned to this.ws. The old socket's queued close event then
nulls out this.ws, silently breaking send() until the next reconnect.
Same risk for delayed open/error/message handlers.
2. Reconnect-after-disconnect. clearTimeout() does not cancel a callback
that has already fired but whose macrotask has not yet run. If
disconnect() lands in that window, the queued reconnect callback
still calls #openSocket() and resurrects the connection.
Every event handler now bails out if this.ws no longer points at the
socket that fired the event, and the reconnect timer callback re-checks
shouldReconnect before opening a new socket.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
