test: drop the remaining wall-clock deadlines from test waits

[MarcoDotIO]

Summary

#25 listed the test waits that still gave up at a wall-clock deadline. The macOS CI job runs about 3,150 tests in parallel on the xcode-27 runner, and the cooperative pool stalls for 5–8 s at a time, so any of these waits could fail even when its condition was about to hold. This PR converts the rest of that list using #25's pattern:

• Poll while !Task.isCancelled with no deadline, using try? await Task.sleep.
• On cancellation, Issue.record a labelled AsyncWaitTimeoutError and then throw it. Swift Testing drops errors thrown after a time-limit cancellation, so the recorded issue is what names the wait that hung.
• Put .timeLimit(.minutes(1)) on every suite or test that reaches one of these waits.
• Replace a timeout that only separated "short path taken" from "long default used" with a value past the time limit, so a regression shows up as a hang.

OpenClawKitTests

Wait	Change
ProviderStreamingCancellationTests.waitUntil(seconds: 5)	Uses the shared waitUntil; suite time limit. The request timeout (policy and URLSessionConfiguration) is now 1 h, so a cancellation that never reaches the request fails as a hang instead of passing when the old 60 s timeout fired.
ModelRouterStreamingFallbackTests 5 s loop	Uses waitUntil; suite time limit. The two adjacent unlabelled polls in the same suite use it too.
RealtimeTalkRelaySession._test_waitForStartupCancelled(timeoutSeconds: 1)	This was not a racy wait. stop() sets isClosed synchronously on the main actor, so the hook returned .cancelled before any timer was armed. The parameter is removed and the hook passes a 0 s timeout, so the test no longer depends on a wall clock at all. A session that is not closed now reports .failed immediately instead of after 1 s. The test has a per-test time limit.
OpenClawChatUITests (1 s)	Done on #25 (45849eb), which this branch is on top of.

OpenClawLinuxRuntimeTests

• New TestAsyncHelpers.swift, the same shape as the one in OpenClawKitTests. It replaces AgentLoopHardeningTests.waitUntil, which did 500 × 10 ms, recorded an unlabelled issue, then returned so the test carried on. Its three callers now pass labels; they already had per-test time limits.
• GatewayServerTestHarness:
  • Recorder.waitFor (5 s) now takes a label and waits until the time limit.
  • collect had the same 5 s bug and 12 callers. It wasn't on the list, but it's in the same file, so it's converted here too. When the time limit cancels it, the for await ends and the helper records and throws.
  • .timeLimit(.minutes(1)) is added to the seven gateway suites that call these helpers.
• One deliberate negative wait is kept. GatewayScopeAuthorizationTests checks that an unregistered connection gets nothing in 200 ms. It now uses frames(_:arrivingWithinMs:). The old call could never fail: whenever the 200 ms timer won the race, the task group returned [] and discarded the frames it had collected. The new helper returns what actually arrived.
• AutomationHardeningTests (10 s × 2): both use waitUntil.
  • addingAJobWakesTheSleepingLoop used its 10 s deadline to tell "woken by the job change" apart from "slept out the 60 s idle cap". Without that deadline, the 60 s cap would race the 60 s time limit.
  • A new DEBUG-only hook, CronScheduler._test_setMaximumSleepSeconds, raises the cap to 1 h in that test. A missed wake now hangs until the time limit and fails.
• SignInWithChatGPTSessionTests (10 s loopback-page wait): uses waitUntil; suite time limit.
• MCPHardeningTests (3 s + 2 s, plus elapsed < 1.5 s, "no request-timeout stall"):
  • Both polls use waitUntil.
  • The request timeout goes from 500 ms to 1 h, and the elapsed assertion is removed. A call or refresh that stalls behind the reader now hangs until the time limit. MCP requests end on cancellation (withTaskCancellationHandler → cancelRequest), so the time limit does end them.
• ChannelAdaptersLinuxSmokeTests.poll (15 s): removed in favour of waitUntil; suite time limit.

Timeouts deliberately kept

• The 200 ms negative window above.
• #expect(throws: .timedOut) / .timeout(...) cases, such as SIWC timeout: 1 and the MCP legacy SSE connect timeout. Those timeouts are the behaviour under test.

Stacked on #25 (which is stacked on #24). Merge those first; until then this diff also includes their commits. Only the last two commits are new: 7661599 (OpenClawKitTests + relay hook) and 3b3466e (Linux runtime).

Test plan

• swift build --build-tests
• Scripts/lint-swift.sh: 0 violations
• Targeted swift test --filter over the 17 affected suites: 96 + 29 tests pass, in about 1 s each.
• Pool starvation, using scratch tests that were not committed. Each run has one starver in the same test target, spawning activeProcessorCount * 2 (28) Task.detached(priority: Task.currentPriority) { usleep(6_000_000) } blockers, which gives about a 12 s stall.
  • Control: a copy of the old Date() < deadline loop with a 5 s deadline fails after 12.0 s. waitUntil on the same condition passes after 12.0 s.
  • Starver next to the real tests, all passing after 12.0–12.5 s (so they were stalled):
    • cancellingBeforeResponseHeadCancelsTheRequest
    • both ModelRouterStreamingFallbackTests cancellation tests
    • "closed relay does not wait for startup ready"
    • the two AgentLoopHardeningTests abort tests and duplicateRunIDsJoinTheActiveRun
    • all 6 GatewayEventStreamTests
    • the collect callers in the scope, approval, presence, organization, wire-shape and branch suites
    • smsWebhookDeliversSignedMessage
    • "Browser sign-in completes through the loopback listener"
    • toolsListChangedOnTheServerStreamRefreshesTheCatalog
  • The two automation tests finished before the starver took hold, so they were checked with scratch copies that spawn the blockers inline right after start() / addJob. The new versions pass after 12.1 s and 12.3 s. The old 10 s loop also passed in this run, because it re-reads the runs after each sleep before checking the deadline. It was converted anyway to remove the wall clock.
• A wait that never holds ends at 60 s with Time limit was exceeded plus Timeout waiting for: <label>. Checked for the Linux waitUntil, collect and Recorder.waitFor.
• Mutation checks, reverted afterwards:
  • CronScheduler.reschedule() with the wake removed: addingAJobWakesTheSleepingLoop fails at 60 s with Timeout waiting for: job run after the wake.
  • MCPClient awaiting the list_changed handlers on the reader, which is the deadlock the test guards against: toolsListChangedOnTheServerStreamRefreshesTheCatalog fails with Time limit was exceeded. With the old 500 ms request timeout, the same bug would have recovered after a request timeout and been caught only by the elapsed bound.
• Full swift test on macOS:
  • OpenClawKitTests passed (3,150 tests in 341 suites).
  • OpenClawKitE2ETests passed (20 tests).
  • OpenClawLinuxRuntimeTests: 581 of 582 passed. The one failure was SpotlightMemoryTests.replyCoordinatorRoutesRepliesToOneInvocationAtATime, a known flake that predates this branch; this PR doesn't touch it. Re-running the target passed all 582 tests.

Not addressed here

A sweep for similar patterns found more waits, outside the list this PR worked from. They need a case-by-case audit, because some are yield loops or intentional bounds:

• Iteration-count polls (for _ in 0..<N { … Task.sleep … }):
  • ApprovalQuestionBrokerTests
  • AgentRuntimeExtensionsTests
  • ExecApprovalHardeningTests
  • GatewayRunLifecycleTests
  • RuntimeIntegrationWiringTests
  • ToolsGatewayMethodsTests
  • GatewayServerChatUICompatTests
  • GatewayNodeSessionRouteTests
  • CoreAIModelRuntimeTests
  • VoiceNoteRecorderTests
  • SystemStateReportingTests
  • MediaPipelineTests
• Elapsed-time assertions:
  • MCPHardeningTests.legacySSEConnectTimesOutWithoutAnEndpointEvent (< 2 s)
  • MCPStdioTransportTests (< 5 s, < 3 s)
  • SpotlightMemoryTests (< 3 s, < 2 s)
  • GatewayRunLifecycleTests (< 5 s)
  • AutomationHardeningTests cron search (< 1 s, synchronous)
  • ChannelAutoReplyTests
  • ModelRoutingTests
• Product timeouts used as positive-path bounds:
  • SIWC signIn(timeout: 20)
  • A2A replyTimeoutMs: 5_000 in the channel smoke test
  • runtime.wait(timeoutMs: 10_000)

🤖 Generated with Claude Code