fix(rendezvous): preserve peer port and handle WS heartbeat behind reverse proxy

[hashbk]

Summary

Fixes two compounding bugs in WebSocket support that caused WSS clients behind a reverse proxy to fail ~90% of the time and experience frequent spurious disconnects.

Closes #26.

Bug 1: X-Real-IP/X-Forwarded-For handling zeroes the peer's port

The WS handshake callback overwrote addr with ip:0 when a forwarded IP header was present, zeroing the peer's port. This addr was then used as Peer.socket_addr — the UDP relay destination — so sendto() to port 0 failed with EINVAL (os error 22), which propagated up and tore down the entire UDP listening socket, disrupting all connected clients.

Fix: Capture forwarded_ip separately via Arc<Mutex<Option<String>>> shared into the handshake closure, and thread it through handle_tcp as a new forwarded_ip: Option<&str> parameter used only for the reported IP string (Peer.info.ip), never for the routable socket_addr. Also handles X-Forwarded-For chains correctly (takes the first/original client entry).

Bug 2: WS read loop missing heartbeat handling

The WS read loop lacked the empty-message heartbeat handling that the plain-TCP branch has. An empty RendezvousMessage parsed successfully but matched no arm in handle_tcp, returning false and closing the WS connection on the client's next keep-alive.

Fix: Mirror the plain-TCP heartbeat handling (empty binary → echo empty response). Also handle Close frames explicitly (break immediately instead of waiting for the 30s idle timeout) and log read errors instead of silently exiting the while let loop.