WebRTCGetStartedVP8Net: log RTP sequence number alongside packet counter (#1582)

Follow-up to #1581. Adds the current RTP sequence number from each
stream's LocalTrack to the per-second 'src' diagnostic line so that
the wrap-around point (seq going from ~65535 to a small number) is
visible in the trace.

Why
---
The data captured under #1581 strongly indicates that audio packets
keep being emitted by the .NET sender ("src" counter and outgoing
RTCP SR PacketCount both increment past the failure timestamp) but
Chrome silently drops them (no packetsLost increment, no
bytesReceived increment). That is the textbook fingerprint of SRTP
authentication failure on the receiver — most plausibly caused by
sender and receiver disagreeing about the SRTP rollover counter
(ROC) at the moment the 16-bit RTP sequence number wraps.

If the hypothesis is correct, the wrap timestamp logged here should
align with the moment Chrome's packetsReceived stalls. The format:

  audio src: 10250 packets seq~65530 (~205s at 50 pps)
  audio src: 10300 packets seq~50    (~206s at 50 pps)   <- wrap

If it doesn't align, the wrap isn't the trigger and the next
candidate to investigate would be TWCC sequence wrap (the
TransportWideCC RTP header extension uses its own 16-bit sequence
across all streams; at ~245 packets/sec total it wraps around
~267 seconds).

Behaviour
---------
Pure observability. No bitstream, timing, or wiring changes from
master. The diagnostic is unconditional like the rest of #1581.

Note: SeqNum exposed by MediaStreamTrack is the *next* sequence
number the track will assign, i.e. one ahead of what was just sent
in the SendVideo / SendAudio call immediately preceding the log
line. So the wrap shows as the logged value transitioning from
near-65535 down to a small number, in the same 1-second log
window as Chrome's audio packetsReceived stalls.

Author attribution: Claude Opus 4.7 (model: claude-opus-4-7),
commissioned by Aaron Clauson — per the convention from #1562.

Author: sipsorcery

examples/WebRTCExamples/WebRTCGetStartedVP8Net/Program.cs

@@ -156,14 +156,34 @@ private static Task<RTCPeerConnection> CreatePeerConnection()
             {
                 pc.SendVideo(rtpTs, frame);
                 int n = System.Threading.Interlocked.Increment(ref videoSrcCount);
-                if (n % 15 == 0) { logger.LogInformation("video src: {Count} frames (~{Sec:F0}s at 15 fps)", n, n / 15.0); }
+                if (n % 15 == 0)
+                {
+                    // Log the current RTP sequence number alongside the
+                    // packet count so the wrap-around boundary
+                    // (65535 -> 0) is visible in the trace.  Hypothesis
+                    // being tested: audio/video stream loss correlates
+                    // with the 16-bit RTP sequence number wrapping for
+                    // the affected stream, suggesting an SRTP rollover-
+                    // counter bug somewhere in SIPSorcery's send path
+                    // (or BouncyCastle's wrapper of it).  Note the
+                    // SeqNum reported here is the *next* number the
+                    // track will assign (one ahead of what was just
+                    // sent), so the wrap shows as the value going from
+                    // ~65535 to a small number around the failure time.
+                    var seq = pc.VideoStream?.LocalTrack?.SeqNum;
+                    logger.LogInformation("video src: {Count} frames seq~{Seq} (~{Sec:F0}s at 15 fps)", n, seq, n / 15.0);
+                }
             };
 
             audioSource.OnAudioSourceEncodedSample += (rtpTs, sample) =>
             {
                 pc.SendAudio(rtpTs, sample);
                 int n = System.Threading.Interlocked.Increment(ref audioSrcCount);
-                if (n % 50 == 0) { logger.LogInformation("audio src: {Count} packets (~{Sec:F0}s at 50 pps)", n, n / 50.0); }
+                if (n % 50 == 0)
+                {
+                    var seq = pc.AudioStream?.LocalTrack?.SeqNum;
+                    logger.LogInformation("audio src: {Count} packets seq~{Seq} (~{Sec:F0}s at 50 pps)", n, seq, n / 50.0);
+                }
             };
 
             // Hook outgoing RTCP Sender Reports. PacketCount is the