fix: keep a seek near the end of the source and the position after seeking back

[devopvoid]

Summary

• A seek made while the decode thread waited for the queue to play out (the last second or two of any source, and all of a short one) was taken for the end of the source. The seek emptied the queue, the wait saw it drained, and the player reported the end of the stream and stopped with the seek still pending. The wait now ends when a seek is pending, and the player carries the seek out instead of ending.
• Audio only moves the position forward, so a position left over from before a backward seek held an audio-only source where it had been until the audio caught up. MediaPacer::Flush now takes the position to start from, and a seek passes its target (plus the loop offset, so getPositionUs() reads the target at once while looping).

Test plan

• seekNearTheEndIsNotLost and positionFollowsABackwardSeekOfAudio fail on the old native code (11 frames and none after the seek; position still 1500000 us) and pass with the fix
• Full media module suite with -Dwebrtc.test.hardwareDecoding=true: 56 tests, 0 failures
• The new tests and the neighbouring seek, loop and pause tests, three more runs in a row