dsh plugin add hangs indefinitely with zero output after install completes on disk (CLI, win32)

[cpero139]

Environment

• dsh 0.2.0-rc.2 (via npx @deepseek-ai/dsh), Node v24.x, Windows 11 (10.0.26100) x64
• pnpm 11.21.0 (installed as npm-shim .cmd only), global registry = npmmirror
• Profile: web (CLI); Desktop Hub v1.4.14 corroborating logs

Symptom

dsh plugin --profile web add @liustack/modsearch@latest never returns.
The console prints nothing at all, and the operation's pnpm.log stays 0 bytes.
Meanwhile the install itself completes on disk: package.json, pnpm-lock.yaml
and node_modules/ under ~/.dsh/profiles/web/ are all written during the
"hung" period. Killing the CLI and re-running the exact same command finishes
in ~550 ms with "Already up to date", exit 0.

Reproduction timeline (single machine, one evening)

1. Attempt 1: same command, hangs silently, killed by user
   (operation-EXhWVP, pnpm.log 0 bytes).
2. Attempt 2 (same command): hangs silently, killed by user
   (operation-gZsEc0, pnpm.log 0 bytes) — but the dependency was already
   written to package.json/lockfile and packages installed.
3. Attempt 3 (immediate re-run): "Already up to date", done in 548 ms, exit 0.

Corroborating evidence from the Desktop Hub

~/.dsh/profiles/desktop/hub.log shows install.start entries that never
receive a matching install.done/install.fail (e.g. dsh-workbuddy-connect),
plus several installs that fail after exactly ~120 s — suggesting some wait
paths hit their bound while at least one does not.

Suspected area

In @deepseek-ai/dsh-plugin-manager, pnpm is spawned as its own group leader
and a successor "waits for" a run recorded in .plugin-manager/run.json when
the previous process exited first. In the execution: "cli" path this wait
appears to produce no output and, in at least one observed case, no bound.
The idle-kill ("silence bound") seems to apply only to captured runs, not to
CLI-inherited stdio.

Suggestions

• Print a line like dsh: waiting for previous plugin run (pid X) to finish…
  when entering the lock/handoff wait.
• Apply the same waitMs bound to the successor-handoff wait in CLI mode as
  the desktop path does.