[Yuncan050115]

Refs #851.

What

defaultRunInstall armed one timer at spawn and SIGKILLed the pnpm child when it fired:

const timer = setTimeout(
  () => child.kill('SIGKILL'),
  options.installTimeoutMs ?? GENERATION_INSTALL_TIMEOUT_MS
)

installTimeoutMs has no caller anywhere in the repo, so 90 seconds is a total-duration hard limit on every generation install. pnpm streams Progress: lines continuously while downloading, so a plugin carrying a large platform payload — dsh-ops@0.4.4 pulls @dsh-ops/bash-win32-x64, 392 MB unpacked — gets killed mid-download on a cold store, code ?? 1 records it as exit 1, and diagnosticLine() has nothing but the last Progress: line to report. The reporter measured pnpm itself finishing in 73.5s on a cold store; the market path adds staging, hoisting and peer validation on top, which lands past 90s deterministically.

Change

The timeout measures idleness again rather than duration. Every stdout/stderr chunk re-arms the 90-second bound, so only a process that stopped talking dies on it. A separate hard ceiling — six minutes per phase — still ends a process that keeps producing output but never finishes; six minutes is chosen so both phases plus staging stay inside the registry lock's own budget (waiters give up at 15 minutes, a lock is judged stale at 20, no heartbeat in between; pnpm-runner already treats that fifteen-minute ceiling as the host contract). Both bounds are overridable and accept only safe positive integers, same guard style as minimumReleaseAge — a 0 or NaN override would otherwise SIGKILL every install on the next tick. A kill whose close never arrives settles after pnpm-runner's five-second grace instead of hanging the promise. Every timeout names itself in the trace and the output (generation install timed out and the pnpm process was killed (…)), so a kill no longer masquerades as a pnpm error in generation.log.

Test plan

• New test/generation-install-timeout.test.ts drives the real defaultRunInstall through a scripted pnpm-like child: continuous progress past the old kill point completes and a generation lands (chunk interval is idle/10 so slow CI cannot starve the re-arm); a silent child dies on the idle bound with the timeout named in detail and the trace; a churning child dies at the hard ceiling; 0 / -5 / NaN / 12.5 overrides fall back to the defaults. All four shapes verified red on origin/main (the first fails with install was killed, the others produce no timeout diagnostic), green with the fix.
• vitest run test/generation-install-timeout.test.ts test/generation-boundary.test.js test/market-installer.test.js test/generation-installer.test.ts: 78 passed / 1 failed — the failure (accepts named Harness fallback links…) reproduces identically on a clean origin/main checkout in this environment.
• tsc --noEmit -p tsconfig.node.json: exit 0. git diff --check clean.
• No cold-store dsh-ops end-to-end: this machine's store is warm. What the fix guarantees is that installs are bounded by stall detection rather than 90s of wall time; the payload itself is bounded only by the six-minute per-phase ceiling.

Not changed deliberately: progress stays "any byte on stdout/stderr"; the six-minute ceiling is a chosen default aligned to the lock budget, not measured per package.

[Yuncan050115]

Adversarial review folded in (48e818e):

• Registry-lock budget conflict. The first cut used a 20-minute hard ceiling, exactly the lock's stale deadline: a two-phase install could hold withRegistryLock ~40 minutes with no mtime heartbeat, and a waiter arriving >5 minutes later would steal the lock from a live owner at 20 — two pnpm processes writing one generation registry. Ceiling is now six minutes per phase, inside the 15-minute waiter line pnpm-runner already defers to.
• Kill grace. A SIGKILL whose close never arrives hung the promise; both clocks now arm a 5-second settle, mirroring KILL_GRACE_MS.
• Unvalidated overrides. Both timeouts accept only safe positive integers now (0/NaN previously meant SIGKILL-on-next-tick); covered by it.each cases.
• Test margins. The continuous-progress case runs chunk interval = idle/10 with success 650ms after the last chunk, instead of 90ms-vs-40ms spacing that could starve on a loaded Windows runner.

Wording: the notice contains the substring "error", so if pnpm emitted an ERR_PNPM_* code before stalling, diagnosticLine() still surfaces that code in detail — the trace and output tail carry the timeout line either way. The close-vs-kill race was confirmed identical to the previous single-timer behavior, not newly introduced. Re-run on 48e818e: timeout suite 7/7, families 78 passed / 1 pre-existing env failure, tsc exit 0.