Measure real EnqueueFrame outcomes, then size the send window to fit RTT

Every "fix" for the mirroring freezes so far has been reasoned from code
rather than measured, because the one counter that could have falsified any
of them was blind by construction: `enqueue_frame` returns as soon as a frame
is *posted* to openscreen's TaskRunner, long before `Sender::EnqueueFrame`
decides whether to accept it. The frame pump's `enqueued_fps` therefore read a
healthy 30fps through every freeze.

Add `BreadcastEnqueueStats` (new FFI accessor, no behaviour change): per-second
counts of OK / MAX_DURATION_IN_FLIGHT / REACHED_ID_SPAN_LIMIT /
PAYLOAD_TOO_LARGE, plus the in-flight window gauges and RTT sampled at the
enqueue attempt, all surfaced on the existing "frame pump rate" line as
`accepted_fps` / `rejected_*`.

Measured against the real Chromecast, that settles it: 12.2% of frames were
being rejected with MAX_DURATION_IN_FLIGHT, in 85% of all seconds -- steady,
not just during visible freezes. Since breadcast enqueues already-encoded
frames, each rejection silently breaks the H.264 reference chain rather than
merely dropping a frame.

The measurement also corrects the diagnosis. The send window is
clamp(2*RTT, kMinSenderInFlight, target_playout_delay/3); the assumption was
that a LAN pins it to the 66ms floor. It does not -- RTT to this receiver runs
42-189ms, so 2*RTT is 84-378ms and the window was pinned at the *ceiling*,
133ms at a 400ms playout delay. The ceiling was the binding constraint, so
raising the floor alone would have changed nothing.

So raise both, ceiling first: target playout delay 400ms -> 1200ms (ceiling
133ms -> 400ms) and kMinSenderInFlight 66ms -> 200ms for RTT dips. Measured
over a matched 65s steady-state window, rejections fall 12.2% -> 4.3% and
seconds containing a broken reference chain 85% -> 40%. Costs ~800ms of
added latency, which is unnoticeable for mirroring to a TV.

This is an improvement, not a cure. The residual rejections are bursts
(in-flight seen at 433ms against a 200ms window, RTT spiking to 221ms), and no
static window survives those. The real fix is the backpressure contract
sender.h documents and this facade still doesn't implement: consult
GetInFlightMediaDuration()/GetMaxInFlightMediaDuration() and throttle *before*
encoding, so a skipped frame never leaves a dangling reference behind.

breadcast-caststream-sys/src/session.cc

@@ -39,6 +39,33 @@ using openscreen::cast::VideoStream;
 // audio-then-video streams collapses to just "index 0 is the video stream."
 constexpr int kVideoStreamIndex = 0;
 
+// The playout delay breadcast asks the receiver for -- the window between
+// capture here and presentation there. Deliberately *not*
+// openscreen::cast::kDefaultTargetPlayoutDelay (400ms), because that value
+// turned out to be the binding constraint on throughput, not just on latency.
+//
+// SenderImpl::GetMaxInFlightMediaDuration() computes the sender's send window
+// as clamp(2*RTT, kMinSenderInFlight, target_playout_delay/3). At a 400ms
+// target that ceiling is 133ms -- about four frames at 30 FPS. Instrumented
+// measurement against real hardware (see BreadcastEnqueueStats in facade.h)
+// found the round-trip time to a Chromecast over Wi-Fi sitting at 57-145ms,
+// i.e. 2*RTT of 114-290ms: consistently *above* that 133ms ceiling. The
+// window was therefore pinned at the ceiling and 3-40% of frames were being
+// rejected with MAX_DURATION_IN_FLIGHT every second, each one silently
+// breaking the H.264 reference chain and freezing the picture until the next
+// key frame.
+//
+// Raising this to 1200ms lifts the ceiling to 400ms, so 2*RTT lands inside
+// the clamp and the window tracks measured network conditions the way
+// openscreen intended, instead of being capped below one round trip. The cost
+// is ~800ms of additional end-to-end latency, which is unnoticeable for
+// screen mirroring to a TV and a straight trade against multi-second freezes.
+//
+// Note this is only the *sender's* half of the fix: it must stay paired with
+// the kMinSenderInFlight patch in vendor/openscreen (see PATCHES.md), which
+// raises the floor of that same clamp for the moments when RTT dips.
+constexpr std::chrono::milliseconds kTargetPlayoutDelay(1200);
+
 VideoStream BuildVideoStream(const VideoParams& params,
                              bool use_android_rtp_hack) {
   Stream stream;
@@ -47,7 +74,7 @@ VideoStream BuildVideoStream(const VideoParams& params,
   stream.channels = 1;
   stream.rtp_payload_type = GetPayloadType(VideoCodec::kH264, use_android_rtp_hack);
   stream.ssrc = GenerateSsrc(/*higher_priority=*/false);
-  stream.target_delay = openscreen::cast::kDefaultTargetPlayoutDelay;
+  stream.target_delay = kTargetPlayoutDelay;
   stream.aes_key = GenerateRandomBytes16();
   stream.aes_iv_mask = GenerateRandomBytes16();
   stream.receiver_rtcp_event_log = true;