refactor: modularize chat backend, update docs for .m4s segments

docs/architecture/adr/ADR-001.md

@@ -19,11 +19,11 @@ We require a completely independent 24/7 linear video channel that broadcasts a
 **Key distinctions**:
 
 - **Playout**: Continuous scheduled program from playlist.
-- **Packaging**: FFmpeg → standard HLS (`.m3u8` + `.ts` segments, 4–6s duration).
+- **Packaging**: FFmpeg → standard HLS (`.m3u8` + `.m4s` segments, 4–6s duration).
 - **Delivery**: Immutable segments served via Cloudflare edge caching + R2 (zero egress cost).
 - **Interaction**: Separate lightweight WebSocket service for chat.
 
-Bandwidth (not storage or compute) is the dominant cost driver. A single viewer at ~4 Mbps consumes ~1.3–1.8 TB/month; 100 concurrent viewers = ~130–180 TB/month. Direct VPS delivery is only viable for PoC/small audiences.
+Bandwidth (not storage or compute) is the dominant cost driver. A single viewer at ~4 Mbps consumes ~1.3–1.8 TB/month; 100 concurrent viewers = ~130–180 TB/month. Direct VPS delivery is only viable for PoC/small audiences. HLS segments are typically `.m4s` files, with `.m4s` being the default for fMP4 segments.
 
 ## Decision Drivers
 
@@ -31,7 +31,7 @@ Bandwidth (not storage or compute) is the dominant cost driver. A single viewer
 2. Full independence and ownership (no video platform lock-in).
 3. Strong US performance and low latency.
 4. True/near-true synchronization via live-style HLS (not pure VOD).
-5. Aggressive immutable caching of `.ts` segments to achieve near-zero egress.
+5. Aggressive immutable caching of `.m4s` segments to achieve near-zero egress.
 6. Browser-native playback (`hls.js` + native HLS).
 7. Lightweight, maintainable stack with modest operational complexity.
 8. Support for custom multi-room + private chat with persistence and moderation.
@@ -58,9 +58,9 @@ Adopt a **self-managed US-East playout + Cloudflare R2 + edge-cached HLS** archi
 
 ### 2. Storage & Delivery (Cloudflare R2 + CDN)
 
-- HLS segments (`.ts`) and manifests uploaded to **Cloudflare R2** (Eastern North America hint `enam`).
+- HLS segments (`.m4s`) and manifests uploaded to **Cloudflare R2** (Eastern North America hint `enam`).
 - Custom domain (`media.linearvoid.tv`) fronted by Cloudflare with **Cache Rules**:
-  - `*.ts` (and init `.mp4` if using fMP4 later): `Cache Everything`, immutable, Edge TTL 24h–1yr (`Cache-Control: public, max-age=31536000, immutable`).
+  - `*.m4s` (and init `.mp4` if using fMP4 later): `Cache Everything`, immutable, Edge TTL 24h–1yr (`Cache-Control: public, max-age=31536000, immutable`).
   - `*.m3u8`: Short TTL (1–10s) or `must-revalidate` (`Cache-Control: public, max-age=1..10, must-revalidate`).
   - Master playlist: TTL ~30s.
   - Tiered Cache enabled where possible.
@@ -90,7 +90,7 @@ Adopt a **self-managed US-East playout + Cloudflare R2 + edge-cached HLS** archi
 
 **Initial Targets**:
 
-- Protocol: Standard HLS (`.ts` segments). Defer LL-HLS/CMAF/WebRTC.
+- Protocol: Standard HLS (`.m4s` segments). Defer LL-HLS/CMAF/WebRTC.
 - Max rendition: 720p30 initially (upgrade to 1080p30 or ABR later).
 - Latency: 15–35s (acceptable for linear programming/chat).
 

docs/architecture/adr/ADR-003-tech-stack.md

@@ -38,7 +38,7 @@ We must explicitly document language/runtime choices per module and the assumpti
 
 1. All video assets **must** be normalized before being added to any playlist (H.264, AAC, 30 fps constant, 2s keyframes, CRF encoding).
 2. Deployment is **Docker-first**; services will be containerized.
-3. Cloudflare is the primary CDN and will be configured with specific Cache Rules (`.ts` immutable long TTL, `.m3u8` short TTL).
+3. Cloudflare is the primary CDN and will be configured with specific [Cache Rules](../../../infrastructure/cloudflare/cache-rules.md).
 4. Chat does **not** require end-to-end encryption in v1 (separate ADR if needed).
 5. Single VPS origin initially; multi-region is a later evolution.
 6. Monitoring focuses on playout health, cache hit ratio, and R2 operation counts.