Replace WebSocket with HTTP + WebRTC only Architecture

[imxade]

Currently all real-time communication in Rein runs over a single WebSocket connection. This is the wrong tool for all three jobs it's doing simultaneously:

1. One-shot RPC calls — token generation, LAN IP lookup, config saves. These are request/response by nature and don't need a persistent socket.
2. Input events — mouse, keyboard, scroll. TCP's head-of-line blocking adds unnecessary latency; if an old mouse coordinate packet is delayed, it blocks newer ones.
3. Screen frame relay — the desktop captures frames and sends them up to the server, which relays them back down to the phone. Every frame passes through the server twice, capping throughput and adding latency.

---

Proposed Architecture

Replace the WebSocket server entirely with two things:

• HTTP REST endpoints for all one-shot calls (token/auth, IP, config, WebRTC signalling).
• WebRTC for all real-time data:
  • A MediaTrack for screen mirroring — P2P, hardware-encoded video, no server relay.
  • A DataChannel for ping and input events — UDP-like, no head-of-line blocking.

The server's only new role is serving the signalling endpoints to bootstrap the WebRTC connection. It never handles video data again.

---

What gets better

• Screen mirroring goes from a manual canvas-capture loop at ~12 fps to a native hardware-encoded P2P video stream (adaptive fps+bitrate).
• Input latency drops — mouse/scroll events are no longer blocked by TCP retransmits.
• Settings page stops opening WebSocket connections for simple lookups — they become plain HTTP calls.
• Server stops relaying video frames entirely.
• ws package will get removed.