fix(pipeline): link the byte-stream capsfilter after h264parse, not before

[snadahalli]

The bug

Starting an AirPlay cast on macOS fails immediately, before any network traffic:

INFO  Desktop capture session ready (native GStreamer source) width=1920 height=1080
INFO  Selected encoder encoder="vtenc_h264" label="VideoToolbox H.264 (Hardware)" hw=true
ERROR AirPlay casting failed
      e=GStreamer error: Failed to link elements 'vtenc_h264-1' and 'capsfilter1'

Capture and encoder probing both succeed. The pipeline itself will not assemble.

Why

vtenc_h264 advertises stream-format: avc on its src pad as a fixed string, not a list — it cannot emit byte-stream at all. The AirPlay chain demanded byte-stream directly from the encoder:

encoder → capsfilter(byte-stream) → h264parse → appsink
          ^^^^^^^^^^^^^^^^^^^^^^^ empty intersection with vtenc_h264

h264parse is the element that converts avc to byte-stream, so it has to come first. x264enc offers { avc, byte-stream }, which is why the identical chain links on Linux and why this survived — and the Miracast pipeline already uses the correct shape (encoder → h264parse → mpegtsmux), which is why Miracast works.

Reduced, the old order reproduces the failure exactly and the new one does not:

$ gst-launch-1.0 videotestsrc ! vtenc_h264 \
    ! 'video/x-h264,profile=high,stream-format=byte-stream' ! h264parse ! fakesink
WARNING: erroneous pipeline: could not link vtenc_h264-0 to h264parse0,
  vtenc_h264-0 can't handle caps video/x-h264, profile=high, stream-format=byte-stream

$ gst-launch-1.0 videotestsrc ! vtenc_h264 ! h264parse \
    ! 'video/x-h264,stream-format=byte-stream,alignment=au' ! fakesink
(clean)

The fix

Move the capsfilter after h264parse, and drop profile=high — vtenc_h264 has no profile property and does not advertise the field, so pinning it would just move the negotiation failure one element downstream.

sender_pipeline.rs (the WebRTC path) carried the same over-constraint and is fixed alongside. It is latent rather than observed there, since that path has no callers. It needs no h264parse: rtph264pay accepts avc and byte-stream alike, so constraining alignment only lets the two negotiate.

Verification

fmt --check clean, clippy --all-targets --all-features -D warnings clean, cargo test --all 207 passed / 0 failed on macOS arm64, plus the reduced gst-launch-1.0 cases above.

Not verified end to end: completing a cast additionally needs Screen Recording permission and a receiver that accepts the connection (see #27), neither of which this PR touches. What is verified is that the pipeline now links.