fix(server): terminal subprocess polling no longer floods the PID space

[rynfar]

Adopts upstream #6377. Terminal subprocess polling spawned a process per terminal, per poll at a 1s cadence — pgrep plus ps on POSIX, powershell.exe on Windows. Several open terminals churned through PIDs fast enough to matter, and PID exhaustion is not confined to Pylon when it happens.

What changed

• One process-table snapshot per poll cycle instead of one per terminal. A single ps reads the whole table; deriveSubprocessInspectResult then walks each terminal's subtree from that snapshot in memory. Per-poll spawns go from O(terminals × commands) to O(1).
• pgrep is gone entirely — the snapshot already answers what it was asked, so that's one fewer spawn per terminal per poll.
• ps resolves to an absolute path once at startup. Spawning by bare name walks every PATH entry, costing one failed posix_spawn per directory until the hit — measurable at a 1s cadence on a long PATH.

This lands squarely on Pylon's "performance without compromise" line, and it's a defect with blast radius outside the app rather than a tidy-up.

Verification

• vp test run apps/server/src/terminal/Manager.test.ts: 54 passed (the commit brings 120 lines of new tests with it).
• vp run -F t3 typecheck: no errors.
• vp lint on both changed files: clean.

Clean cherry-pick — no Pylon adaptation needed, and no conflict with anything Pylon has diverged on here.

Not exercised end-to-end against a live terminal with several sessions open; the behaviour is covered by the unit tests rather than an integration pass.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 2a8dd3c.

This comment will update automatically after the next completed run.