[Feature]: Explore single-port UDP multiplexing for multi-client WebRTC

## Problem Statement

Rein currently serves its UI and WebSocket signaling on TCP port 3000 while `werift` allocates a separate UDP ICE socket per peer connection from a configured range. LAN hosts therefore need both TCP 3000 and a UDP range in their firewall configuration.

Explore whether all WebRTC clients can share one UDP port while HTTP and WebSocket signaling continue on TCP using the same numeric port, without relying on a cloud service or external TURN server.

## Proposed Solution

Run a focused research spike and prototype for multi-client ICE UDP multiplexing.

The investigation should cover:

- How STUN username fragments, remote address tuples, DTLS, SRTP, and SCTP packets can be demultiplexed on a shared UDP socket.
- Whether the current `werift` stack can be extended cleanly or whether upstream support is feasible.
- Whether TCP 3000 and UDP 3000 can be used concurrently as separate protocol sockets.
- Correct routing for multiple simultaneous viewers and reconnect overlap.
- Preservation of Rein's single `RTCPeerConnection` per viewer and ordered/unordered DataChannel behavior.
- Security, authentication, denial-of-service, cleanup, and observability implications.

The deliverable should be a documented recommendation plus a minimal prototype if the approach is viable.

## Alternatives Considered (Optional)

- Keep the existing bounded ICE UDP range.
- Embed a local TURN relay.
- Move media to WebTransport or WebSocket-based transport.
- Adopt a WebRTC stack with native ICE UDP-mux support.

Alternatives should be compared for latency, portability, maintenance cost, and LAN-only operation.

## Additional Context (Optional)

Suggested acceptance criteria:

- Document the limitations of the installed `werift` version and candidate implementation paths.
- Demonstrate two concurrent clients and reconnects through one shared UDP listener, or clearly document why this is not viable.
- Verify video, `input-unordered`, and `input-ordered` traffic remain functional.
- Require no external server or cloud dependency.
- Keep the GStreamer RTP relay on `127.0.0.1:5004`; it must not become externally accessible.
- Update firewall and architecture documentation if a solution is adopted.

## Checklist

- [x] I have searched for existing feature requests to avoid duplicates