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.

.github/workflows/ci.yml

@@ -92,8 +92,18 @@ jobs:
         run: pnpm typecheck
       - name: Lint
         run: pnpm lint
+      # `test:windows` caps the fork pool at 2 instead of `pnpm test`'s
+      # unbounded default. Five specs in this suite really start processes
+      # (tests/agent-pty, pty-deps, pty-helpers, install-powershell,
+      # smoke): node-pty's ConPTY helper and a cold `powershell.exe` are
+      # both console-bound, and this 2-core runner made parallel spawning
+      # the amplifier behind every red `Test` step in the 2026-09-09/10
+      # window — six real 5000 ms timeouts (agent-pty `:71`/`:106`,
+      # install-powershell `:105`, the latter measuring 12.1 s) and two
+      # silent vitest worker deaths. The test bodies now carry their own
+      # explicit timeouts as well; this just stops them starving each other.
       - name: Test
-        run: pnpm test
+        run: pnpm test:windows
       - name: Build
         run: pnpm build
       - name: Check consumer type surface
@@ -131,11 +141,26 @@ jobs:
       # Pin the DSH CLI the lane mounts into; the profile's bundle stack
       # (dsh-base / dsh-web-app) resolves from this installation. Keep in
       # step with the plugin's @deepseek-ai/* peer range when bumping.
-      # DSH 0.1.5-rc.1 is the `latest` (and `next`) dist-tag on npm — the
-      # 0.1.5 line's first release candidate; the lanes speak the slash-only
-      # RPC dialect (tests/e2e/host-protocol.ts).
+      # DSH 0.1.5-rc.2 is the `next` dist-tag on npm (`latest` still points
+      # at rc.1); the lanes speak the slash-only RPC dialect
+      # (tests/e2e/host-protocol.ts).
+      #
+      # `--legacy-peer-deps` + the larger heap are the fix for the two ways
+      # this step used to die (runs 34492160123 / 34491256626 / 34490912649
+      # and 34363627184): the pinned version's TRANSITIVES are declared as
+      # floating `^` ranges, so while upstream publishes a prerelease in
+      # stages (0.1.5-rc.2 went out 14:43-14:57 on 2026-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 package that only appeared minutes later. Skipping peer
+      # negotiation keeps the install deterministic; the accumulated heap
+      # covers npm's worst case for this ~520-package tree. Mounting a
+      # version-mismatched bundle tree is not silent here: the mount smoke
+      # below boots the real shell and would fail loudly.
       - name: Install dsh CLI (pinned)
-        run: npm install -g @deepseek-ai/dsh@0.1.5-rc.1
+        env:
+          NODE_OPTIONS: --max-old-space-size=4096
+        run: npm install -g --legacy-peer-deps @deepseek-ai/dsh@0.1.5-rc.2
 
       # lib/ is gitignored; the tarball is produced from this build.
       - name: Build and pack the npm tarball