feat(65): the clip mux — a third output on the same ffmpeg, drained off the frame path

Slice 2 of TASK 65. 602 green, 0 warnings. **Clips are still off**: no `ClipBuffer` is passed, so the
ffmpeg command line is byte-for-byte what it was before this commit, and a test asserts exactly that
(the original args are a strict prefix of the new ones).

- `FfmpegArgs` appends a fragmented-MP4 output to `pipe:1` only when `ClipBuffer` is set. One-second
  fragments (`-frag_duration 1000000`) rather than the 4 s GOP, so a clip can start inside the window
  instead of at the last keyframe. Stats already own stderr, so stdout was free.
- `Fmp4FragmentSplitter` turns that byte stream into whole fragments: `ftyp`+`moov` is the init
  segment, each `moof`+`mdat` is a fragment. It parses box headers itself, survives a box being cut
  anywhere across reads, and **resyncs instead of throwing** — a clip fault must never take the stream
  down.
- `FfmpegEncoder` reads it on its own task, never blocking the frame path. Any exception logs and
  disables clips for the session; the broadcast is untouched.
- `IEncoderProcess` gained `StandardOutputBytes` (the seam already had the text reader for probing).

Next slices: the replay layer + retention, then the Settings switch with disabled-but-remembered controls.

Services/Encoder/EncoderOptions.cs

@@ -50,6 +50,11 @@ public sealed class EncoderOptions
     /// <summary>Name of the mixer's audio pipe (default <see cref="DefaultAudioPipeName"/>).</summary>
     public string AudioPipeName { get; init; } = DefaultAudioPipeName;
 
+    /// <summary>TASK 65: when set, the encoder muxes a SECOND video output into this ring (fragmented
+    /// MP4 on stdout) for the replay buffer. Null = clips off, and the ffmpeg command line is exactly
+    /// what it was before the feature existed.</summary>
+    public Services.ClipRing? ClipBuffer { get; init; }
+
     /// <summary>GOP in frames = Fps × 4s — the YouTube keyframe ≤ 4s compliance bound.</summary>
     public int GopSize => Fps * 4;
 }