fix(standalone): revert Windows signal forwarding to TerminateProcess

CTRL_BREAK_EVENT delivery is unreliable on Windows — the scheduler's
threading.Event.wait doesn't wake on SIGBREAK from a different thread
context, so the parent's children-watcher loop never empties and Ctrl+C
hangs the whole tree. Reported by Chip; reproduced on the AWS WorkSpace.

The orphan-postgres bug that motivated the CTRL_BREAK_EVENT switch is
already addressed by the other half of fde7321 — children call
ensure_standalone_setup() instead of get_server(), so they no longer
register PIDs in pgserver's on-disk handle list. Force-killing them
is safe; only the parent owns the pgserver handle and exits via the
normal atexit path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: aarthy-dk

testgen/__main__.py

@@ -146,12 +146,16 @@ def _install_shutdown_handler(handler) -> None:
 
 
 def _forward_signal_to_child(child: subprocess.Popen, signum: int) -> None:
-    # POSIX: forward the signal verbatim. Windows: send CTRL_BREAK_EVENT so the
-    # child's atexit hooks run (it deregisters from pgserver's PID list, lets
-    # streamlit/uvicorn shut down their event loops, etc.). The child must have
-    # been spawned with CREATE_NEW_PROCESS_GROUP — see _subprocess_spawn_kwargs.
+    # POSIX: forward the signal verbatim. Windows: TerminateProcess — graceful
+    # CTRL_BREAK_EVENT delivery is unreliable here because some children
+    # (notably the scheduler thread blocked in threading.Event.wait, and
+    # Streamlit/tornado) don't wake on SIGBREAK, leaving the parent's
+    # children-watcher loop hung forever. Force-kill is safe: children no
+    # longer call pgserver.get_server(), so there's no on-disk PID registry
+    # state to clean up — only the parent owns the pgserver handle and
+    # exits via the normal atexit path.
     if sys.platform == "win32":
-        child.send_signal(signal.CTRL_BREAK_EVENT)
+        child.terminate()
     else:
         child.send_signal(signum)