Backend restart orphans every pty on Windows, no re-attach possible

Repro: start the server, open two sessions that each spawn a shell through node-pty (I use it to drive `claude` CLI sessions from the browser), then kill the server process — ctrl-c, or let nodemon restart it, or let it crash. Check the sessions table afterward: rows still say status='running' for sessions that no longer exist anywhere.

On Linux, a pty is a kernel device with a life partly independent of the process that opened it; tools like screen and tmux exploit that to detach and reattach. Windows has nothing equivalent. node-pty on Windows backs onto ConPTY, and the pseudoconsole handle is owned by the process that created it. When that process dies, the ConPTY instance and everything hosted under it — the console host, the shell, the child process tree — goes with it. There is no /dev/pts/N to walk back into after the fact. A restarted server gets a cold start: new PIDs, new pseudoconsole, zero connection to whatever was running a second ago.

So any row marked 'running' at the moment the process dies is now false, and nothing tells the database that, because the death usually isn't graceful. A crash or a manual restart skips whatever cleanup code would normally flip the row to 'stopped'. Without a fix, the UI lists sessions that don't exist — phantom sessions the user can click into and get nothing back from.

Fix is a reconciliation pass on boot, before the HTTP/WS server starts accepting connections: on startup, select every row where status='running' and mark it 'crashed' (or 'stopped', labeled honestly). I don't bother trying to verify liveness by PID first, because in this architecture there's no code path where a 'running' row survives a process restart — the pty and its PID are children of the server itself, not detached, so if the server just started, every prior 'running' row is by definition stale.

Ordering matters: this has to finish before the server calls `listen()`. If a client reconnects and the app re-reads session state while reconciliation is still running, it can catch a row mid-flip and briefly show a session as alive again. Running the reconciliation synchronously in the startup function, ahead of accepting connections, avoids that race.

The general lesson: any state you persist about an in-process resource (pty, worker thread, in-memory socket) needs a boot-time sweep if the process can die without running its own cleanup path. You can't rely on graceful shutdown as the only writer of the terminal state.