fix: forward browser headers in WebSocket upgrade handshake

[abdushakurob]

Fixes #61

Polling worked through the tunnel but WebSocket upgrades failed. The
backend never saw the handshake. The problem was in the local ws dialer:
when the CLI opens the matching ws://localhost connection to the backend,
it was only forwarding a minimal header set and passing
Sec-WebSocket-Protocol incorrectly as a plain header instead of through
the ws constructor's subprotocol argument.

Socket.IO's upgrade handshake is stricter than a bare WebSocket server
about headers like Origin, which is why this surfaced there specifically
while plain WebSocket backends tolerated it fine.

Changes

• Forward relevant browser headers (origin, cookie, authorization,
  referer, user-agent) from the tunnel edge into the local ws dialer
• Pass subprotocol correctly via the ws constructor's second argument
  instead of setting Sec-WebSocket-Protocol as a plain header
• Tighten WSProxy to forward only relevant headers rather than replaying
  all incoming headers including hop-by-hop ones

Testing

Added packages/core/src/client.ws-upgrade.test.ts to prevent this
regression from coming back. It checks two things: that the tunnel client
can forward a WebSocket upgrade to a plain WebSocket backend, and that it
preserves the headers Socket.IO cares about, especially Origin, so a
Socket.IO server can accept the upgrade instead of staying stuck on
polling or timing out.

In short, the test proves the tunnel is replaying the browser's upgrade
context correctly, not just opening a socket.

Both cases pass locally. Also built core, CLI, and tunnel packages,
all clean.

[vercel]

@abdushakurob is attempting to deploy a commit to the Akinkunmi Team on Vercel.

A member of the Team first needs to authorize it.