Deflake the surface bridge progress and zmx watcher tests

[sbertix]

Summary

CI went red three times on main today without a related code change. Two classes of flake:

• GhosttySurfaceBridgeTests.removeRacingRescheduleKeepsFlushHealthy and
  progressDriverRestartsAfterStaleRemoval asserted the trailing flush after a
  single TestClock advance. Under parallel-bundle load the freshly spawned
  flush task can register its sleep after the advance, so the tick no-ops and
  the value sticks at the leading edge ((progressValue -> 30) == 90). Same
  class as the coalescing flake fixed in Fix coalescesBurstOfProgressReports flake by advancing until the flush lands #638; these two were left on single
  advances.
• ZmxSessionWatcherRegistryDeliveryTests.deliversSequenceThroughOnOSCSequenceOnMainActor
  timed out its 3s real-time semaphore budget on a saturated runner.

Changes, test-only except a read-only seam:

• Fold the bounded advance-until loop into a shared
  settleThenAdvance(_:by:until:) helper and use it at every trailing-flush
  assertion.
• progressDriverRestartsAfterStaleRemoval: coarsen the idle interval and
  widen the stale window so teardown converges within the loop bound even when
  a starved tick lands a single wake, while the re-arm ticks can never accrue
  a second stale REMOVE.
• removeRacingRescheduleKeepsFlushHealthy: assert the pre-tick applied
  sequence, so a cancelled flush task clobbering the live handle now fails
  deterministically (previously both healthy and clobbered runs converged to
  the same final state).
• determinateValuePaintsPromptlyAfterIdlePeriod: drain the in-flight flush
  (new isProgressFlushIdleForTesting seam mirroring the leading-edge gate)
  before asserting the leading-edge paint, with the drain budget kept below
  the stale window so a stale REMOVE can never stand in for a real drain.
• zmx watcher tests: raise the five positive real-time waits to a shared 30s
  budget; a passing run still signals in milliseconds, only a failing run ever
  waits this long. The negative start-after-stop wait keeps its short budget
  by design.

Type of change

• Bug fix (the linked issue is a bug report)
• Feature (the linked issue is a feature request marked ready)
• Documentation
• Other (CI test flakiness)

How was this tested?

Full suite run four times while iterating; final tree fully green, including
all previously flaking tests.

• make check passes (format + lint)
• make test passes
• I built and ran the app to confirm the change works

Checklist

• This pull request is linked to an issue with Closes # above.
• For a feature, the linked issue is labeled ready.
• I am the author of this work and accountable for it; no commit is authored or co-authored by an AI agent.
• I have read the Contributing guide and the Code of Conduct.