fix(ci): stop the Windows lane's real timeouts and the mount lane's npm failures

Two independent, evidence-backed defects in the 2026-09-09/10 CI window
(60 completed runs: 26 success / 17 failure; ci-windows|Test red 8 times,
plugin-mount|Install dsh CLI red 4 times).

1. Windows: six of the eight red ci-windows runs were genuine 5000 ms
   vitest timeouts in specs that really start a process —
   `tests/agent-pty.spec.ts` (`:71` / `:106`; a PowerShell + ConPTY pair per
   terminal) and `tests/install-powershell.spec.ts` (`:105`; a cold
   `powershell.exe` start measured 12.1 s). vitest.config.ts sets no
   testTimeout, so both suites ran on the 5000 ms default, and
   `waitForTranscript`'s own poll budget was *also* 5000 ms — the inner wait
   consumed the whole outer budget, which is a structurally guaranteed
   timeout, not a flake. Both suites now declare a 30 s budget (describe-level
   options, verified working on vitest 4) and the inner poll drops to 15 s so
   it stays strictly below the outer bound.

2. Windows: `ci-windows`'s Test step runs `pnpm test:windows`
   (`vitest run --maxWorkers=2`, the script added with the baseline commit)
   instead of `pnpm test`. Five specs spawn real processes, node-pty's ConPTY
   helper and a cold powershell.exe are both console-bound, and an unbounded
   fork pool on a 2-core runner is the amplifier behind both the timeouts
   above and the two silent worker deaths (`Worker exited unexpectedly` with
   0 FAIL and every file reported passing — one of them on a commit whose
   sibling run was green). Local `pnpm test` semantics are unchanged; only the
   Windows lane is bounded.

   The worker-death mode itself is NOT proven fixed here: it does not
   reproduce on macOS and the two occurrences have no same-commit rerun. This
   is the evidence-backed part; the real Windows result decides whether more
   is needed, and retries are deliberately not used to paper over it.

3. plugin-mount: `npm install -g @deepseek-ai/dsh@<ver>` never really pinned
   anything — the pin's transitives are floating `^` ranges, so while upstream
   publishes a prerelease in stages (rc.2 went out package by package between
   14:43 and 14:57 UTC on 09-10) npm resolved a mixed rc.1/rc.2 peer graph:
   3062 ERESOLVE lines then `Ineffective mark-compacts near heap limit`
   (exit 134), or a hard ETARGET on a sibling that appeared 5.5 minutes (resp.
   25 seconds) later. The same mechanism hit the alpha line on 09-09. The lane
   now pins an already-complete rc.2 and passes `--legacy-peer-deps` plus
   `NODE_OPTIONS=--max-old-space-size=4096` to decouple the install from the
   upstream publish window; a mismatch would not be silent because the mount
   smoke in the same lane boots the real shell.

   The stale comment claiming rc.1 is both `latest` and `next` is corrected —
   it documented a reality that had already changed.

tests/install-powershell.spec.ts

@@ -69,7 +69,15 @@ afterEach(() => {
   for (const dir of tempDirs.splice(0)) rmSync(dir, { recursive: true, force: true })
 })
 
-describe('PowerShell installer entry points', () => {
+/**
+ * The Windows cases here spawn a real PowerShell (`powershell.exe` 5.1 or
+ * `pwsh`) per assertion, and a cold 5.1 start on a loaded 2-core CI runner
+ * measured 12.1 s (ci-windows run 34494370187) — more than twice vitest's
+ * 5000 ms default, which is why this file kept losing that case. The
+ * file-content cases below share the suite budget but finish in
+ * milliseconds either way.
+ */
+describe('PowerShell installer entry points', { timeout: 30_000 }, () => {
   it('keeps the UTF-8 BOM required by Windows PowerShell 5.1 -File decoding', () => {
     expect(readFileSync(INSTALLER).subarray(0, 3)).toEqual(Buffer.from([0xef, 0xbb, 0xbf]))
   })