#17655 test(cmux-next): the busy work-queue test bounds against its deadline, not 100 ms

Summary

MainActorWorkQueueTests.failsFastWithBusyBeyondTheLimit measured 0.289 s against a 100 ms bound on #17611 under the full parallel suite.

The test needs to show that a full queue answers busy right away instead of waiting for room. No frame fires before the third call, so a queue that waited could only answer when the deadline expired, and it would answer with a timeout, not busy. The deadline is now 30 s and the bound is 10 s, so the test still catches a waiting queue and a loaded runner can't trip it.

Test-only.

Testing

• Not run locally (fleet builds only). This PR's cmux-next swift test job is the green check.

Changelog

none

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Fixes a flaky MainActorWorkQueueTests failure that measured 289 ms against a 100 ms bound under the full parallel suite.

• Bounds the busy fast path against its 30 s deadline with a 10 s bound, still catching a queue that waits while tolerating loaded runners.
• Test-only change; no production behavior or changelog impact.

---

[!NOTE]
Low Risk
Test-only timing and documentation changes with no production code impact.

Overview
Relaxes timing in failsFastWithBusyBeyondTheLimit so it stays reliable on loaded CI: the request deadline goes from 5 s to 30 s, and the assertion that the third call returns busy quickly is loosened from 100 ms to 10 s (still well under the deadline so a queue that waits for a timeout would still fail).

Adds an inline comment documenting that the old 100 ms ceiling flaked at ~289 ms on a parallel runner (#17611). Test-only; production MainActorWorkQueue behavior is unchanged.

^{Reviewed by Cursor Bugbot for commit 87e992dbe0282d8376e37148c713023c16dc5d6f. Bugbot is set up for automated code reviews on this repo. Configure here.}