test(playback): make GetCurrentTimeProgression robust to CI timing

CurrentTime is the wall-clock playback position, so grabbing buffered frames
faster/slower than real-time (common on shared CI runners) makes (time2 - time1)
deviate from 5/frameRate in both directions. The previous symmetric +/-50%
EXPECT_NEAR failed (near-)consistently on the windows-2022 runner while passing
on windows-2025. Keep the forward-progress assertion (EXPECT_GT) and replace the
brittle tolerance with a generous upper bound; deterministic progression is
already covered by GetCurrentFrameIndexProgression.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: wysaid

tests/test_file_playback.cpp

@@ -718,9 +718,14 @@ TEST_F(FilePlaybackTest, GetCurrentTimeProgression) {
     double frameRate = provider.get(ccap::PropertyName::FrameRate);
     double expectedTimeDelta = 5.0 / frameRate;
 
-    // Allow some tolerance for timing variations
-    EXPECT_NEAR(time2 - time1, expectedTimeDelta, expectedTimeDelta * 0.5)
-        << "Time progression should roughly match frame rate";
+    // CurrentTime reports the wall-clock playback position, not a frame counter, so
+    // grabbing buffered frames faster or slower than real-time (as happens on shared CI
+    // runners) makes (time2 - time1) deviate from 5 / frameRate in both directions. The
+    // reliable invariant is forward progress, asserted above; keep only a generous upper
+    // bound here to catch gross regressions without flaking on timing. The deterministic
+    // frame-count progression is covered by GetCurrentFrameIndexProgression below.
+    EXPECT_LT(time2 - time1, expectedTimeDelta * 5.0)
+        << "Time progression should stay within a sane multiple of the frame-rate span";
 
     provider.stop();
     provider.close();