DEV-C1 follow-up: wire epoch→RTCP Sender Report on the wire (RTSP server runnability)

[aperim-agent]

Context

The pre-hardware readiness audit (workflow wc3tvqa4w, 2026-06-11) confirmed a major but honestly-disclosed seam in DEV-C1 (outbound presentation epoch, merged PR #113):

• HLS EXT-X-PROGRAM-DATE-TIME is genuinely epoch-stamped end-to-end ✅ (the working, validated outbound timing path).
• The epoch→RTCP Sender Report path is a dangling seam — never emitted on the wire. SharedEpoch → SrStamper is built but has no runnable consumer: the RTSP output server warns+skips and is not instantiable from the CLI (a pre-existing gap that predates this program, per crates/multiview-output/src/rtsp_server/).

Evidence: crates/multiview-output/src/rtsp_server/sink.rs:71,84; crates/multiview-output/src/rtcp.rs:146; crates/multiview-output/src/rtsp_server/server.rs:330.

Why this is tracked, not a blocker

• No invariant Bump actions/checkout from 4 to 6 #1/Bump vite from 6.4.3 to 8.0.16 in /web #10 risk: the epoch is read-only over the seam, feature-gated, and never instantiated — it cannot pace or stall the engine.
• HLS PDT covers the epoch-presentation use case today; RTCP SR is the RTSP-transport equivalent.
• Fully wiring it requires making the RTSP output server CLI-runnable, which is a separate, larger deliverable (an RTSP serving path) outside the devices/display/cast/timing program scope.

The work

1. Make the RTSP output server instantiable/runnable from the CLI (the larger pre-existing gap).
2. Wire SharedEpoch → SrStamper into the runnable serve so RTCP SR NTP↔RTP pairs derive from the same epoch as HLS PDT.
3. Hardware-validate: capture RTSP RTCP SRs (Wireshark) and confirm SR NTP↔RTP agrees with HLS PDT for the same instant (no drift).

Until then, DEV-C1's RTSP-SR sub-deliverable should be marked in docs/development/work-schedule.md as parked-behind-RTSP-runnability rather than fully done.