fix(signaling): handle race between DataChannel open and WebSocket close

[1ureka]

Summary

Fixes a race condition in the signaling phase where a successfully
established tunnel could be incorrectly torn down immediately after
connection.

Root Cause

After the WebRTC DataChannel opens, the host's deferred wsConn.Close()
fires and propagates a read error to the client's r.watch() goroutine.
On a LAN, this error arrives within milliseconds of the DataChannel open
event, leaving the select in EstablishAsClient (and EstablishAsHost)
with two ready cases simultaneously: tr.Ready() and errCh.

Go's select resolves ties pseudo-randomly, so roughly 50% of CLI-mode
LAN connections were terminated with a false "failed to read signaling
messages" error — even though the tunnel was healthy.

Fix

Added a non-blocking tr.Ready() check inside the errCh case of both
EstablishAsHost and EstablishAsClient. If the DataChannel is already
open when the WS error is received, the error is treated as an expected
post-handshake cleanup rather than a failure.