killProcessOnPort() was a no-op on win32 (POSIX-only, via lsof/kill),
so a restart could leave the old OpenCode process holding the port
while a new instance spawned on a different one. That's a plausible
contributor to a chronic pattern seen in production logs: repeated
"OpenCode process exited, restarting" cycles and hundreds of
ECONNRESET/proxy errors over multiple days on Windows.
Give killProcessOnPort a real Windows branch: parse `netstat -ano`
for PIDs listening on the target port, filter out our own pid, and
force-kill each via `taskkill /PID <pid> /F` (no /T -- we don't own
that process, so only the listener itself is killed, not any
children it may have).
waitForPortRelease()'s existing soft-fail-and-warn behavior is left
untouched -- it's a deliberate safety net for any platform where the
port doesn't free up in time, not just Windows, and the restart
already rebinds event-stream readers to the actual resulting port via
onOpenCodeRestarted.
Sérgio Pedro
ced65062c8