shell.run step sequencing silently stalls (reports running:true indefinitely) under concurrent pterm runs

Summary

shell.run steps inside a run[] array (e.g. a Pinokio app's update.js/install.js) can silently stall between steps — the spawned cmd.exe shell finishes its current command and sits idle at a prompt, but Pinokio never sends it the next command. pterm status/GET /apps/logs keep reporting "running": true, "state": "starting" indefinitely even though nothing is happening. Once, the whole control plane (port 42000) also briefly dropped ECONNREFUSED and came back on its own, unrelated to anything the client did.

Environment

• Windows 11, Pinokio desktop app (Electron), driven via pterm (npm pterm CLI) rather than the UI.
• Reproduced twice independently, both times while running two pterm start <script> --ref <app> calls concurrently against two different locally-installed apps, on a machine with heavy background CPU/GPU load from unrelated processes.

Repro

1. Have an app registered under PINOKIO_HOME/api/<app> with a multi-step run[] script (e.g. conda install → node resolve-release.js → npm ci → npm run build → a Python venv bootstrap step).
2. Kick off pterm start <script.js> --ref pinokio://127.0.0.1:42000/api/<app> for two different apps at the same time.
3. Watch pterm status <app> / pterm logs <app> --script=<script.js>.

Observed

• One or both runs get through the first one or two shell.run steps (confirmed via the step's own console output and via the git checkout it performed), then stop producing any further output.
• pterm status continues to report "running": true, "running_scripts": ["<script.js>"], "state": "starting" for 10+ minutes with no change.
• Cross-checking with Get-CimInstance Win32_Process (Windows) shows the cmd.exe child Pinokio spawned for the step is still alive, but has near-zero cumulative CPU time and zero child processes — i.e. it is sitting idle at its prompt, not doing work. The command that finished (e.g. node resolve-release.js) had already printed its final line and returned to the prompt; the next step in run[] (e.g. npm ci) was simply never sent to it.
• Stopping the run (pterm stop <script.js> --ref <app>) and restarting it from scratch works and usually completes normally — sometimes on the first retry, sometimes needing 2–3 attempts.
• Separately (once, not consistently reproduced): the whole control plane became briefly unreachable — pterm status/logs calls threw ECONNREFUSED 127.0.0.1:42000 for a short window — and then came back with a new process start time for Pinokio.exe, suggesting an internal restart, without any user action.

Impact

Any script driving Pinokio programmatically (via pterm) cannot reliably tell "stalled" apart from "still working" from the reported state alone — it has to fall back to OS-level process inspection to detect a real stall, which most callers won't do. This makes unattended/automated use of pterm start/run on a multi-step script unreliable, especially under concurrent app runs or background system load.

What would help

• Any internal timeout/heartbeat on step-sequencing, so a step that never gets dispatched surfaces as an error state rather than an indefinite "running": true.
• Or: documentation of a known concurrency limit (e.g. "only run one pterm start at a time") if that's the actual constraint, so callers can serialize themselves.

Happy to provide more diagnostic detail (Pinokio version, log excerpts) if useful — this repro is from real, if slightly indirect, use rather than a minimal isolated test case.