Explore an SFU path for larger, broadcast-style rooms

## Problem

`PeerMesh` is a genuine full mesh: one `RTCPeerConnection` and one data channel per remote participant, with no media server anywhere in the stack. That's the right call at this product's target room size (small, focused working sessions — see [ADR-0002](https://github.com/hoangsonww/Threadline-RealTime-Collab/blob/main/docs/decisions/0002-webrtc-mesh-not-sfu.md)), but per-participant bandwidth and CPU cost scales with the number of *other* participants, which puts a real, known ceiling on room size.

## Proposed solution

This is deliberately an exploration, not a fully-specified change:

- Prototype an SFU-backed path (Cloudflare Calls, LiveKit, or a self-hosted mediasoup/janus instance) as an *alternative* mode for rooms above some participant threshold, without ripping out the existing mesh for small rooms.
- Figure out where SFU signaling would live — likely still relayed through `RoomDurableObject`, since it already owns presence and signaling relay, or as a fully separate service.
- Write up the tradeoffs as a new ADR (following the pattern in [`docs/decisions/`](https://github.com/hoangsonww/Threadline-RealTime-Collab/blob/main/docs/decisions/README.md)) before writing implementation code — this is exactly the kind of decision that ADR conventions exist for.

## References

- [`docs/roadmap.md`](https://github.com/hoangsonww/Threadline-RealTime-Collab/blob/main/docs/roadmap.md) — "Full mesh only, no SFU path"
- [`ARCHITECTURE.md#why-each-decision-was-made-this-way`](https://github.com/hoangsonww/Threadline-RealTime-Collab/blob/main/ARCHITECTURE.md)
- [ADR-0002](https://github.com/hoangsonww/Threadline-RealTime-Collab/blob/main/docs/decisions/0002-webrtc-mesh-not-sfu.md)