Never set waitingOnFrames if a replay is not attached

[peppy]

For next release to see if it helps with the seeking backwards issue. Or gives us more clues.

[bdach]

Well I attempted to exercise this by doing a crude

diff --git a/osu.Game/Rulesets/UI/FrameStabilityContainer.cs b/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
index b49924762e..a291cc014c 100644
--- a/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
+++ b/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
@@ -31,6 +31,7 @@ public sealed partial class FrameStabilityContainer : Container, IHasReplayHandl
 
         public bool AllowBackwardsSeeks { get; set; }
         private double? lastBackwardsSeekLogTime;
+        private bool weDidALittleTrolling;
 
         /// <summary>
         /// The number of CPU milliseconds to spend at most during seek catch-up.
@@ -127,6 +128,13 @@ public override bool UpdateSubTree()
 
         private void updateClock()
         {
+            if (!weDidALittleTrolling && Time.Current >= 5000)
+            {
+                Logger.Log("TROLLING HAS OCCURRED");
+                waitingOnFrames.Value = true;
+                weDidALittleTrolling = true;
+            }
+
             if (waitingOnFrames.Value)
             {
                 // if waiting on frames, run one update loop to determine if frames have arrived.

and I didn't get a 12-second seek back, but I did get a 1-frame pause:

[runtime] 2024-03-06 08:34:13 [verbose]: TROLLING HAS OCCURRED
[runtime] 2024-03-06 08:34:13 [verbose]: GameplayClockContainer stopped via call to StopGameplayClock
[runtime] 2024-03-06 08:34:13 [verbose]: GameplayClockContainer started via call to StartGameplayClock

So I'd give this a 50-50 chance of doing something to fix the issue (or fix most of it but not fix it completely)...