test(site-memory): stop the suite flaking on Windows git handles and timer skew

[Agnik47]

Two src/site-memory tests fail in CI for reasons that have nothing to do with what they assert. Both are environmental, both land on unrelated branches, and between them they have reddened main and several open PRs.

1. Windows: git handles outlive the test

Unit tests (windows-latest, shard 1/2) fails intermittently. It hit #481 on 3 Sep and #483 on 4 Sep, and that shard has gone red on main several times recently. The failure is always the same shape:

FAIL  src/site-memory/checkpoint.test.ts > checkpoint compare-and-swap > returns a stale-revision conflict…
Error: Test timed out in 5000ms.
Error: EBUSY: resource busy or locked, rmdir 'C:\Users\RUNNER~1\AppData\Local\Temp\webcmd-checkpoint-t05DZ4\.webcmd\sites'

The two errors are one cascade, not two problems:

1. Each of these tests spawns several real git processes against a throwaway home. That costs a second or two on an idle machine and several times more under a parallel suite on Windows, where process creation is expensive — past vitest's 5s default.
2. vitest aborts the test mid-git. afterEach then removes the temp directory while a git child still holds .git, so the recursive remove fails too — reported against the same test, and looking like a filesystem bug rather than a clock.

I reproduced both locally on Windows, including the identical EBUSY … \.webcmd\sites path. The tests pass in isolation (checkpoint.test.ts: 48 tests, 43s) and only fail under full-suite parallelism, which matches CI exactly.

Fix — size the budget to what these tests do, and let cleanup tolerate the handles. Both live in one support module, __fixtures__/git-test-support.ts, so the reasoning and the numbers have a single home:

• GIT_TEST_TIMEOUT_MS = 20_000, applied per file via vi.setConfig. Not a new policy — it is the value the slowest tests in these same files had already opted into individually (}, 20_000)); applying it per file makes the class consistent instead of whack-a-mole. It does not hide a hang: a test that never finishes still fails, at 20s.
• removeTempDirs() passes maxRetries/retryDelay to rm. Node retries EBUSY/EPERM/ENOTEMPTY for exactly this case, but maxRetries defaults to 0.

Applied to the eight site-memory test files that drive real git. No production code changes — the EBUSY is a test-cleanup artifact, not a product defect. I checked file-lock.ts for a leaked descriptor before concluding that; it closes its handle in a finally, so retrying is not papering over a leak.

2. Any platform: the seed lookup budget is asserted to the millisecond

The first push of this PR went green on both Windows shards and then failed on Unit tests (ubuntu-latest, shard 2/2):

FAIL  src/site-memory/seed-client.test.ts > global seed client > aborts after two seconds and does not retry
AssertionError: expected 1999 to be greater than or equal to 2000

aborts after two seconds and does not retry asserts that a lookup guarded by AbortSignal.timeout(2000) took at least 2000ms by Date.now(). Node can run the timer callback when only 1999ms have elapsed by that clock — libuv compares against a loop time it caches and truncates to whole milliseconds, so the two disagree by up to a millisecond.

Fix — the bound exists to show the lookup waited for the timeout instead of returning early, which a millisecond of slack still shows. The upper bound that proves it did not retry is unchanged.

Verification

On Windows 11, Node 22:

• Before: every full-suite run reproduced the Windows failure locally — checkpoint.test.ts and self-learning.integration.test.ts timing out at 5000ms and then failing cleanup with the same EBUSY … \.webcmd\sites.
• After: three consecutive full-suite runs, zero site-memory git failures. The only remaining site-memory failures on my machine are four EPERM: symlink tests, which need Developer Mode and fail identically before this change.
• A scratch test that sleeps 6s passes under vi.setConfig({ testTimeout: GIT_TEST_TIMEOUT_MS }), confirming the file-level budget takes effect — it would fail at the 5s default.
• CI on the first push confirmed the Windows half: Unit tests (windows-latest, shard 1/2), the job that had been failing, passed.
• npm run typecheck clean.

Notes

• The per-test }, 20_000) markers left in these files are now redundant with the file default. I left them rather than widen the diff; happy to strip them if you'd prefer.
• Two other tests time out under the same load and are deliberately not touched here, since they are a different area and want their own change: src/hosted/programmatic-differential.test.ts (5s timeout) and src/browser/run/runner.test.ts (EBUSY unlinking chrome_debug.log).

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[rishabhraj36]

cherry picked the commit so closing this