v0.5.2: custom start times survive a track change

Playing a track with an iTunes start time (e.g. "Pretty Girls is a
Motherfucker", 0:40) began at 0:00 whenever another track was already
loaded. QMediaPlayer.setSource() synchronously emits two status changes
before returning: a LoadedMedia still reporting the *outgoing* source,
then LoadingMedia for the new one. The stale first event consumed the
one-shot _pending_start_ms armed in Round 22 and seeked the dying
pipeline, so the new track's real LoadedMedia ~5 ms later found nothing
armed. Only the first track after launch worked.

The armed seek now carries the URL it belongs to and is consumed only
when source() matches. tests/test_round32.py models the real Qt event
sequence, which Round 22's plain MagicMock never emitted; the
test_round8/test_round22 stubs now report the new source by the time its
LoadedMedia arrives, as Qt does.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/test_round22.py

@@ -94,6 +94,10 @@ class TestSameSourceReplay:
             == [(QUrl.fromLocalFile(t2.location),)]
         # New source: the seek waits for LoadedMedia as before.
         assert player._local._pending_start_ms == 30_000
+        # Qt reports the new source by the time its LoadedMedia arrives; since
+        # Round 32 the armed seek is only consumed when the two match (see
+        # tests/test_round32.py for the stale-event sequence that motivated it).
+        player._local._media.source.return_value = QUrl.fromLocalFile(t2.location)
         player._local._on_media_status(player_module.QMediaPlayer.MediaStatus.LoadedMedia)
         player._local._media.setPosition.assert_called_with(30_000)
         assert player._local._pending_start_ms == 0