fix(console,sdk): tear down console/dev children so they cannot spin at 100% CPU

[eladb]

Summary

Fixes #6861 — Console dev script orphaned node processes at 100% CPU.

Root cause

Detached simulator sandboxes were not reliably cleaned up on stop:

• Simulator.stop() refused to run while starting; console fires start without awaiting it.
• Sandbox.cleanup() only SIGTERM without SIGKILL escalation.
• Console HTTP close never terminated the tRPC WebSocketServer; dev.mjs had no force-exit timeout.

Fix

• Allow stop-during-start; escalate sandbox cleanup to SIGKILL; close WSS before HTTP server; harden scripts/dev.mjs shutdown.

Test plan

• SDK sandbox-cleanup + stop-while-starting tests
• Existing cleanup + service tests
• WSS close unblocks server.close
• Manual: console app dev Ctrl+C leaves no 100% CPU orphans

[github-actions]

Thanks for opening this pull request! 🎉
Please consult the contributing guidelines for details on how to contribute to this project.
If you need any assistance, don't hesitate to ping use over Discord.

[eladb]

Pushed 27df3e338 with the fixes from the adversarial review. The headline issue: the new regression test in this PR only checked that the SDK's _running state machine reported "stopped" — it never verified the detached sandbox child was actually reaped. So the bug the PR was meant to fix (the "no handle" branch in stopResource short-circuiting without calling resource.cleanup()) would have persisted undetected.

What 27df3e338 does:

• Reap the sandbox in the "no handle" branch (simulator.ts:529-553): the resource is mid-init when HANDLE_ATTRIBUTE hasn't been written to state yet, but its handle IS in _handles.paths. New HandleManager.tryFindHandleByPath(path) does the inverse lookup so stopResource can call resource.cleanup() (the path that reaches Service.stop() → sandbox.cleanup()), then deallocates the handle and deregisters the policy. This is the actual fix for Console: the dev script sometimes doesn't close and consumes 100% CPU #6861.
• Stop-guards in startResource (simulator.ts:1054-1079): bail out of writing to state[path].attrs if a stop is in progress between the init() and save() awaits, so a concurrent stopResource doesn't leave a TypeError: Cannot set properties of undefined in its wake.
• Defensive _stopRequested = false in update() (simulator.ts:417-420): a leaked flag from a previous aborted start would otherwise silently skip starting resources on hot-reload.
• killProcessTree in onChildError (sandbox.ts:332-343): matches the cleanup() path so grandchildren are reaped too, not just the immediate child.
• Strengthened test (stop-while-starting.test.ts): the handler now writes its own PID to a file (path passed via Service.env), and the test polls until the file exists, calls sim.stop(), and asserts process.kill(pid, 0) throws. This would have caught the orphan bug. forceTimer.unref?.() → forceTimer.unref() in dev.mjs while I was there.

The four low-severity findings (rewording a misleading comment, removing the beforeExit listener — confirmed unnecessary, a handle-map leak after mid-init teardown, an inconsistency between onChildError and cleanup() kill style) are folded into the same commit.

Pre-existing prettier warnings on sandbox.ts line 108 and simulator.ts line 184 are untouched — they're not from this PR. Local tsc/eslint/vitest runs are blocked by the missing .gen/ in fresh clones (see #7266); CI will be the real test.