fix(process): Stop actually kills the dev server (#90)

[alamb-hex]

Closes #90 — "Stop returns success while next-server keeps running."

The bug, in four layers

1. startProject spawned with { shell: true, detached: false }, so child.pid was the sh -c wrapper, not the real next-server.
2. stopProject sent SIGTERM to that wrapper. POSIX sh doesn't forward signals, so the server survived and kept its port.
3. It then returned { success: true } having verified nothing.
4. The ss/kill -9 fallback only ran if the tracked kill threw, which it never did — dead code in the common case.

Observed live yesterday: two orphaned sh -c node / node server.js pairs held port 3000, a plain SIGTERM couldn't reach them, and a fresh start failed with EADDRINUSE.

The fix

• detached: true so the child is a process-group leader.
• Group kill — process.kill(-pid, …) reaches the whole tree. Windows degrades to a single-process kill.
• Verified success — poll checkPort after signalling, escalate SIGTERM → SIGKILL, and return success: false with a clear error if the port is still bound. Reporting success while a server lives was the entire bug.
• The port-based fallback is now a real path, including when there's no tracked entry at all — an orphan from a crash, or a server started before HexOps launched.
• stopProject is now async; its caller and runWithDevServerGuard updated.

Also fixed along the way: stoppingProjects leaked permanently for untracked ids, suppressing the next genuine crash notification for that project.

Review found five blockers, all fixed

Two were serious enough to call out:

• A shipped test executed process.kill(-6666, 'SIGKILL') for real. It asserted only success === false, which held whether the signal hit nothing or destroyed an unrelated process tree — so it could never fail because of it. On a box running ~35 dev servers that's a live hazard. process.kill is now mocked structurally in a shared beforeEach; verified with a tripwire config that traps the real syscall — 31 tests, zero hits.
• A deliberate Stop was misreported as a crash. stoppingProjects was gated on "is the child live" rather than "does a tracked child exist". With shell: true the wrapper can exit while a grandchild holds the pipes and the port — the P1: Stop returns success while next-server keeps running — orphans accumulate #90 shape itself — so 'close' fired with intentional: false, and with restartOnCrash enabled it relaunched the server the user just stopped. Verified by reverting the guard in a temp copy and watching the new test fail with exactly that notification.

Plus: stopByPort now refuses process.pid/process.ppid (a project misconfigured to :3000 would have made HexOps kill its own server); runWithDevServerGuard aborts rather than running pnpm install against a still-live server (newly reachable, since a failed stop is now a real outcome); and a SIGINT/SIGTERM handler reaps tracked children, because setsid() severed the foreground group that used to do it.

Verification

399 tests / 46 files, tsc --noEmit clean, pnpm build exit 0.

Real processes, not mocks — SIGKILL escalation against a SIGTERM-ignoring server on a scratch port: stopProject returned success after 4.2s, port free, all 8 group pids dead.

Known follow-ups (issues to file)

• M3 is ineffective in the real shape. The process-exit confirmation checks the tracked child, which under shell: true is the sh wrapper — killed instantly by the group SIGTERM, so the guard always passes. A server that closes its listener then hangs returns success: true with the port free and the process still alive. Only affects servers that trap SIGTERM (a stock Next dev server doesn't), but it's a narrower instance of P1: Stop returns success while next-server keeps running — orphans accumulate #90.
• The SIGINT/SIGTERM handler leaks listeners across module re-evaluation. Registration is module-scoped, so an HMR reload adds another; the oldest wins and holds a stale process map, silently reaping nothing. SIGHUP is unhandled.
• override-remove doesn't check blocked, so a failed guard-stop surfaces as success there.
• A failed guard-stop skips the restart in finally.
• shell: false projects are force-killed 500ms after releasing their port.