Fix Windows flake in CommandChannelDecoderTest

[ascheman]

Verify / windows-latest jdk-8 intermittently fails whole CommandChannelDecoderTest runs with:

org.junit.platform.commons.JUnitException: Failed to close extension context
Caused by: java.io.IOException: Failed to delete temp directory C:\...\Temp\junit-...
  Suppressed: java.nio.file.DirectoryNotEmptyException

Observed three times within a week on unrelated PRs (#3392, #3395 — e.g. https://github.com/apache/maven-surefire/actions/runs/30089175667/job/89469589427 and run 30089211662); every re-run is green.

Root cause: the test class initializes DumpErrorSingleton into the JUnit @TempDir, and several tests write .dumpstream files there. On Windows a freshly written file can be transiently locked (antivirus/indexer) exactly when the @TempDir cleanup runs — the cleanup throws and fails the whole class. Surefire's own I/O is fine (all dump writes use try-with-resources), and JUnit 5.14's resilient cleanup retries evidently do not close the gap.

Fix: write the dumps under target/decoder-dumps/ instead — no post-test cleanup needed at all, mvn clean removes them, and the files remain inspectable after CI runs. CommandChannelDecoderTest is the only test class using this pattern.

---

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates Surefire Booter unit tests to avoid intermittent Windows temp-directory cleanup failures by moving dumpstream output out of JUnit’s @TempDir and into the module’s target/ directory, where it won’t be deleted as part of per-test cleanup.

Changes:

• Remove JUnit @TempDir usage from CommandChannelDecoderTest.
• Initialize DumpErrorSingleton to write dump files under target/decoder-dumps/ to avoid Windows file-lock timing issues during temp cleanup.
• Add in-code rationale describing the Windows flake and why target/ is used instead.