test: keep browser-run temp dirs in the OS temp dir

[Agnik47]

Two unit tests fail on my Windows box against main, and the cause turned out to be a POSIX-absolute path used where the OS temp dir was meant.

What happens

src/browser/run/runner.test.ts seeds its persistent-context tests with:

const userDataDir = fs.mkdtempSync('/tmp/webcmd-persistent-browser-run-');

/tmp is not the OS temp dir off POSIX. On Windows it resolves against the current drive, so the tests either write into <drive>:\tmp when that directory happens to exist, or fail outright with ENOENT when it does not. I found a stale D:\tmp\ on my machine that these runs had created.

The same file already gets this right ~350 lines further down:

const baseDir = fs.mkdtempSync(path.join(os.tmpdir(), 'webcmd-artifact-'));

so this looks like a slip rather than a deliberate choice. os and path are already imported at the top of the file.

On top of that, both tests call chromium.launchPersistentContext() inside the test body while still on Vitest's 5s default. A cold persistent-context launch does not reliably fit in that budget, and under a full-suite run they time out:

FAIL |unit| src/browser/run/runner.test.ts > runBrowserProgram > hides sibling Session pages in a persistent context
Error: Test timed out in 5000ms.

Run on their own with a wider budget, the same two tests finish in ~3.5s — the launch is fine, the 5s allowance is not.

src/pipeline/steps/download.test.ts has the same slip: the cookie test passes a hardcoded dir: '/tmp/webcmd-download-test' and really does create that directory in the drive root, while the sibling test right above it already resolves the identical name through os.tmpdir().

Change

• Resolve all three temp paths through path.join(os.tmpdir(), ...).
• Give the two persistent-context tests 20_000, matching the per-test budget already used for process-launching tests in src/hosted/main-lifecycle.test.ts.

Five lines, tests only, no production code touched.

Why CI is green today

The unit job does not install Playwright browsers, so describeWithChromium (runner.test.ts:35) skips this whole block on CI. The failures only surface for a contributor who has Chromium locally — which is exactly where they are most annoying.

Verification

On Windows, against main:

• Full unit suite: 32 failures before, 30 after. Both runner.test.ts failures are gone. The other 30 are pre-existing and unrelated to this change — 26 need Windows symlink privileges (EPERM: operation not permitted, symlink), and 4 are separate hosted-path and timeout issues that also fail on unmodified main.
• runner.test.ts alone: 89/89 pass. Together with download.test.ts: 92/92.
• npm run typecheck clean.
• No webcmd-download-test is recreated in the drive root after a run.

Left out on purpose

session-manager.test.ts and provider.test.ts pass baseDir: '/tmp/webcmd-test' in ~40 places and do create <drive>:\tmp\webcmd-test\cloak\profiles. Those tests currently pass, and converting them is mechanical churn that would bury this diff, so I left them for a separate change. Happy to do that one next if you want it.

[github-actions]

🟢 No documentation gap found — high confidence

The pull request only changes tests, lockfiles, generated metadata, or dependency metadata.

This review is advisory and does not block merging.