JUnit 5 @Timeout under Maven Surefire thread-pooled parallel execution

Investigate how JUnit 5's @Timeout annotation interacts with Maven Surefire's thread-pooled parallel execution when test methods modify shared static fixtures. JUnit 5's default test runner operates single-threaded, while Surefire's parallel execution modes introduce a thread pool that can reorder test invocation and persist static state across concurrently running instances. The @Timeout hard timeout is enforced per test method, but its handling relative to Surefire's thread scheduling and task queue is not documented for concurrent contexts, especially when static fields are mutated by other threads. JUnit 5.8's revised parallel execution policy further alters latency behavior, yet no built-in mechanism isolates @Timeout timing from thread-pool interference.

Under what conditions does @Timeout fire before or after Surefire's thread pool completes a test method? Does concurrent modification of static fixtures amplify latency spikes that @Timeout either masks or exacerbates? How does the 5.8 parallel execution policy change affect predictable timeout enforcement?