Fix video recovery freeze on RTP seq number wrap

After a prolonged decode stall on an SFU (where the sender does not
back off under loss), the 16-bit RTP sequence number can advance by
more than half its range. This breaks two independent state machines
in the video receive pipeline, each freezing video for 60-150s:

1. RtpFrameReferenceFinder wrapper: AheadOf<uint16_t>(cleared_to, seq)
   misjudges a fresh frame as "already cleared" and drops it before it
   reaches a per-codec finder. Fixed by requiring the 32-bit RTP
   timestamp (unambiguous over ~6.6 hours at 90 kHz) to also confirm
   the frame is older before dropping. This is wrap-safe for all frame
   types and backwards-compatible (callers that pass no timestamp keep
   the original sequence-number-only behavior).

2. RtpSeqNumOnlyRefFinder: stale GoP entries from before the wrap sit
   "ahead" of the new keyframe in 16-bit space, shadowing upper_bound()
   lookups so delta frames are dropped ("has no GoP"). Fixed by
   removing GoPs that appear ahead of a newly-arrived keyframe -- a
   keyframe is the newest frame received, so an "ahead" GoP can only be
   a stale leftover.

Both fixes address the same root cause (16-bit wrap ambiguity) at
different pipeline stages and are strictly less aggressive at dropping.

Tested: 3 new unit tests in rtp_frame_reference_finder_unittest.cc
(FrameNotDroppedWhenSeqWrapsButTimestampNewer,
ClearToSeqNumOnlyWithoutTimestamp,
DeltasNotDroppedByStaleGopAfterSeqNumJump); negative control confirms
the GoP test fails without the fix. Validated end-to-end on iOS against
a production SFU: 60-150s freeze plus 80s 1fps tail reduced to
immediate full-frame-rate recovery.

Bug: webrtc:516639936
Change-Id: I9790e3cf5cd6590b899de3e32d39f6d573ff205d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/477641
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#48053}