Flaky: ExecutionTimeTests.Completes_Within_Unhappy* exceed 1s wall-clock bound on macOS CI #7159

What happened

ExecutionTimeTests.Completes_Within_Unhappy and Completes_Within_Unhappy2 failed on the modularpipeline (macos-latest) job of PR #7139. That PR only changes assertion source generators, so it did not cause the failure.

failed Completes_Within_Unhappy2 (2s 361ms)
  AssertionException: Expected to be less than 00:00:01
  but received 00:00:01.3215153
  at Assert.That(duration).IsLessThan(TimeSpan.FromSeconds(1))
failed Completes_Within_Unhappy (2s 246ms)
  but received 00:00:01.1886545

• Run: https://github.com/thomhurst/TUnit/actions/runs/39325689765/job/118310813974
• Test: tests/TUnit.Assertions.Tests/ExecutionTimeTests.cs, lines 31 and 55

Why it is flaky

Each test sets a CompletesWithin(250ms) timeout. It then asserts that the whole wall-clock duration, measured with a Stopwatch, stays under 1s. That duration also includes the throw/catch path and the message-regex assertion. On a loaded macOS arm64 runner it reached 1.19s and 1.32s, even though the 250ms timeout fired correctly.

Reproduce

Run TUnit.Assertions.Tests on a busy or slow machine, for example the macOS GitHub runner, using --treenode-filter "/*/*/ExecutionTimeTests/*".

Expected

The tests should check that CompletesWithin stops waiting well before the 10s action finishes. They should not depend on a tight 1s wall-clock bound. A bound such as < 5s still proves the timeout fired early and leaves room for CI jitter.