perf: skip Console.Out/Err FlushAsync when no output captured

[thomhurst]

Summary

Every test unconditionally awaits two FlushAsync calls in the finally block, producing two extra async state machines per test for the common case where nothing was written to stdout/stderr. Estimated ~1.5-2% CPU reduction, -2 state machines per test.

Evidence

TUnit.Engine/Services/TestExecution/TestCoordinator.cs:141-151:

finally
{
    await Console.Out.FlushAsync();
    await Console.Error.FlushAsync();
    ...
}

CPU-sampling trace shows AsyncMethodBuilderCore.Start at 16.39% inclusive / 2.93% self — test execution dispatches dozens of state machines per test, and these two are unconditionally created even when output redirection captured nothing.

Proposed fix

• Have the output interceptor set a HasCapturedOutput flag on the context when it first writes.
• Only flush when the flag is set.

Expected impact

• ~1.5-2% CPU.
• Removes 2 async state machines per test.

[claude]

This issue is a focused sub-issue of #5528 ("perf: runtime engine optimizations"), specifically addressing item #4 in that tracking issue:

Unconditional Console.Out/Error.FlushAsync on every test (no-op)
TUnit.Engine/Services/TestExecution/TestCoordinator.cs:143-144

Note that #5528 item #4 proposes a slightly different fix (removing the calls entirely or guarding on ConcurrentStringWriter type), while this issue proposes a HasCapturedOutput flag on the context. Both approaches are valid — the flag approach preserves flush correctness if the writer is ever replaced, while the type-guard approach is simpler but more brittle.