Relax wall-clock bound in canonical capture timeout test

[malpern]

Summary

• The Swift Testing test "Canonical capture timeout returns first-class timed-out evidence" asserted started.duration(to: clock.now) < .milliseconds(250) against a real ContinuousClock. On a loaded CI runner it measured 268 ms and failed PR Add per-key wear and highlight variation to the keyboard stage #1243's build-and-test job (run 30470376137) despite being unrelated to that change.
• SystemValidator.boundedCapture has no injectable clock (its timeout uses Task.sleep on the default clock), so rather than a larger refactor, the assertion keeps the real-clock measurement but widens the bound to a generous 5-second hang guard with a comment. The test still fails if the timeout path hangs instead of promptly returning first-class timed-out evidence, and the captureStatus == .timedOut assertion is unchanged.

Testing

• TEST_FILTER=SystemValidatorTests ./Scripts/run-tests-safe.sh — all 17 tests passed.

Review gate

• ./Scripts/review-gate.sh: remote review gate selected; GitHub claude-review must pass before merge.

🤖 Generated with Claude Code

[claude]

Widening the upper bound from 250ms to 5s (with the explanatory comment) is a reasonable fix for CI flakiness, but it substantially weakens this assertion's ability to catch a real regression — a runaway boundedCapture that overruns its 10ms deadline by, say, 1-2s would now pass silently. If flakiness was the driver, consider a middle-ground bound (e.g. 1-2s) or CI-only widening via an environment check, to keep some signal against a hang while still tolerating scheduler jitter. No other correctness/reliability issues in this diff.

[claude]

Reviewed the diff — no blocking issues. One minor observation: widening the bound from 250ms to 5s fixes the flakiness on loaded runners, but it also means the test would now pass even if boundedCapture's actual deadline enforcement regressed to, say, 1-4s instead of its documented 10ms — i.e. the test can no longer catch a meaningful mid-range latency regression, only a true hang. If that trade-off is intentional for stability, no changes needed; just flagging it as reduced test-coverage precision.