fix: run data source initialization outside test timeout scope

[thomhurst]

Summary

• Fixes bug: SharedType.PerTestSession fixture initialization is cancelled by individual test timeouts #4772 — When a [ClassDataSource<T>(Shared = SharedType.PerTestSession)] fixture implements IAsyncInitializer, its InitializeAsync() was running inside the timeout wrapper of whichever test triggered it first. If that test had a short [Timeout], the fixture initialization would get cancelled — causing ALL tests sharing the fixture to fail.
• Split the slow path (retry + timeout) in TestCoordinator into two phases: data source initialization runs outside the timeout, and only the test body + hooks run inside the timeout.
• Console output during data source initialization now routes to the real console via GlobalContext instead of being captured in a test's output buffer.

Changes

File	Change
TUnit.Engine/Services/TestExecution/TestCoordinator.cs	Added PrepareAndInitializeOutsideTimeoutAsync helper; slow path splits lifecycle into Phase 1 (outside timeout) and Phase 2 (inside timeout)
TUnit.Engine/TestExecutor.cs	Added bool skipInitialization = false parameter to ExecuteAsync to avoid re-initializing data sources already initialized by Phase 1
TUnit.Engine/Logging/TestOutputSink.cs	Log/LogAsync detect GlobalContext and write to OriginalConsoleOut/OriginalConsoleError instead of capturing to context output writers

How it works

Before (broken):

RetryHelper.ExecuteWithRetry:
  TimeoutHelper.ExecuteWithTimeoutAsync:         ← timeout wraps everything
    ExecuteTestLifecycleAsync
      └─ CreateInstance → Prepare → ExecuteAsync
           └─ InitializeTestObjectsAsync          ← slow init eats timeout budget
           └─ test body

After (fixed):

RetryHelper.ExecuteWithRetry:
  Phase 1 (OUTSIDE timeout):
    - CreateInstance, check skip, Prepare
    - InitializeTestObjectsAsync                  ← runs with original CancellationToken
  Phase 2 (INSIDE timeout):
    - ExecuteAsync(skipInitialization: true)       ← only test body + hooks
  Finally:
    - OnDispose + DisposeTestInstance

The fast path (no retry, no timeout) is unchanged — it has no timeout to worry about.

Test plan

• Verify existing tests still pass
• Test with a PerTestSession fixture with IAsyncInitializer that takes 10+ seconds, paired with a test that has [Timeout(5_000)] — the fixture should initialize fully and the test should only start its 5s timeout after initialization completes
• Verify console output during initialization goes to real console, not test output buffer

🤖 Generated with Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

The fix properly addresses #4772 by restructuring timeout enforcement. Previously, the timeout wrapped the entire test lifecycle (initialization + hooks + test body), which caused shared fixtures with slow initialization to be cancelled when triggered by tests with short timeouts. Now the timeout only wraps the test body execution, allowing data source initialization and hooks to run outside the timeout scope.

Key improvements:

• Correct scoping: Timeout now applies only to the test body via TestExecutor.ExecuteAsync, not the entire lifecycle
• Preserves retry semantics: The retry wrapper still functions correctly, with each retry attempt getting the proper timeout
• Clean implementation: Uses existing TimeoutHelper patterns with no new allocations in hot paths
• Maintains fast path: Tests without retry/timeout continue through the optimized fast path unchanged

The deleted AsyncDependencyInjectionDataSourceSourceAttribute.cs was confirmed as a duplicate file with no external references.