Race condition in `provider.unit.test.ts` due to slow initial execution

從 provider.unit.test.ts 和 AttachProcessProvider suite 開始，然後在緩慢或冷啟動的環境中執行 npm run test，以重現逾時和後續的 stub 失敗。完成的標準是 suite 中的第一個測試能可靠地完成，且 Linux 和 macOS 的斷言通過，同時呼叫不會在測試之間洩漏。

📝 Description

We are observing intermittent test failures during the first run of the unit tests, specifically within the AttachProcessProvider suite.

The root cause appears to be a Race Condition triggered by slow environment startup:

1. First Test Timeout: The first test case (e.g., Linux process list) takes longer than 2000ms to resolve (likely due to initial module loading or environment lag), causing a Mocha timeout error.
2. Polluted Assertions: While the second test is running, the asynchronous call from the first (timed-out) test finally completes.
3. Double Call Error: This causes the sinon stub (like plainExec) to record an extra call during the second test's execution context, leading to an assertion failure: expected plainExec to be called once but it was called twice (or similar).

  586 passing (6s)
  27 pending
  2 failing
  1) Attach to process - process provider
       The Linux process list command should be called if the platform is Linux:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/vscode-python-debugger/vscode-python-debugger/testDir/out/test/unittest/attachQuickPick/provider.unit.test.js)
  	at listOnTimeout (node:internal/timers:585:17)
  	at process.processTimers (node:internal/timers:521:7)

  2) Attach to process - process provider
       The macOS process list command should be called if the platform is macOS:
     AssertError: expected plainExec to be called once and with exact arguments 

🛠 Steps to Reproduce

1. Run tests in a resource-constrained environment (like a cold GitHub Actions runner or a slow local machine).
2. Execute npm run test (or the equivalent test runner command).
3. Observe that the first test fails with a timeout, and subsequent tests fail because stubs were called by the "ghost" of the previous failed test.
4. Run the tests again immediately; observe that all tests (including the previously failed ones) now pass.

Environment: CI (GitHub Runner) https://github.com/ZA139/vscode-python-debugger/actions/runs/25676102630/job/75374288168 / Local Windows