control both clocks in the chapter-selection hold test; widen the Findaway wait ceiling

[mauricecarrier7]

What

AudiobookPlaybackModelTests.test_chapterSelection_holdsDisplayedLocationAgainstTheTrackBeingLeft depended on two real timers:

• It slept 1.6 s so that the 1.5 s skip-suppression window would lapse.
• It expected the navigation hold to still be in force afterwards. The hold clears itself 3 s after a selection.

On ios-core's iOS 26.5 run 36931526869, which pins the toolkit at #237, the test took 22.8 s. The hold had already cleared when the leaving track's tick arrived, so a tick from the track being left must not move the display failed. Elsewhere in that run, CursorTests.testPrevItem took 15.7 s, so stalls of that length do happen on these runners.

How

• AudiobookPlaybackModel now reads all of its suppression windows through wallClock (added in make three timing-dependent tests assert behaviour instead of wall-clock bounds #237, default Date()). These are the save, transient-position and playback-poll windows.
• The hold's fallback timeout now comes from navigationHoldTimeout, which defaults to 3.0.
• Production behaviour is unchanged.
• The test advances the wall clock past the window and sets the hold timeout beyond the length of the test. As a result, only the target's own position can release the hold. A main-queue drain replaces the 150 ms sleep after each emit.

Verification

• Full toolkit suite, run locally on an iOS 26.2 simulator: Executed 315 tests, with 1 test skipped and 0 failures.
• Both AudiobookPlaybackModel test classes ran 10 iterations each: 230 executions, 0 failures.
• I broke the behaviour two ways to confirm the test catches it:
  • Bypassing the track-key gate in acceptPositionUpdate fails the first assertion.
  • Leaving the hold set after the target's position arrives fails the last assertion. Before this change, the 3 s timeout could hide that case.

Also: Findaway eventually() ceiling, 5 s to 30 s

On this PR's first CI run (36932958123), FindawayPlayerAsyncContractTests.testQueuedManipulation_runsAfterTheDebounceAndClearsTheQueuedState failed after 10.9 s. That test is not touched by the change above.

The test already waits on its condition rather than sleeping. Its 5 s ceiling ran out before the 0.5 s debounced work item had run, so this is a slow runner rather than a code fault. I raised the helper's default ceiling to 30 s and documented the reason in a comment. Both callers wait for an event that does happen, so a passing run still returns as soon as it does.

That class also ran 5 iterations locally: 115 executions, 0 failures.

Not done: this PR does not change the other wall-clock waits in the suite.