Revert "viewer HTTP: Content-Type application/octet-stream, not video/mp2t"

This reverts commit 0a253bd919.

The Content-Type change was a misdiagnosis. The real cause of VLC's
"no demux modules matched" was a missing `vlc-plugin-dvb` package on
the test machine — Arch/CachyOS ship the MPEG-TS demuxer plugin
(`libts_plugin.so`) in a separate package from `vlc`. Without it, VLC
falls through to the PS demuxer and misidentifies the H.264 stream.
With the package installed, `video/mp2t` opens cleanly.

`video/mp2t` is the correct Content-Type for an MPEG-TS stream and is
what we should be sending. Documentation of the package requirement
and a runtime check follow in a separate commit.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

src/host/wayland.rs

@@ -225,15 +225,8 @@ async fn serve_capture(listener: TcpListener, mut gst_stdout: ChildStdout) {
         return;
     }
 
-    // Content-Type intentionally application/octet-stream, not video/mp2t.
-    // VLC eagerly maps video/mp2t to demux="ts" and bypasses content
-    // probing; its ts demuxer's Open then fails on the live HTTP stream
-    // with "no demux modules matched" and the input never opens. With a
-    // non-video Content-Type, VLC falls back to byte-probing, which finds
-    // the TS sync pattern and opens cleanly. mpv probes regardless of
-    // Content-Type, so it's unaffected.
     const RESPONSE: &[u8] = b"HTTP/1.1 200 OK\r\n\
-        Content-Type: application/octet-stream\r\n\
+        Content-Type: video/mp2t\r\n\
         Cache-Control: no-cache, no-store\r\n\
         Connection: close\r\n\
         \r\n";