windows: avoid conPTY deadlock when debugger pauses conout worker

[deepak1556]

The conPTY output connection is established on a worker thread before the main Node.js thread calls the native connect implementation. Calling conptyNative.connect() before that worker reports readiness is unsafe because the native implementation synchronously calls ConnectNamedPipe() for the input and output pipes.

From ETW trace reported by @connor4312, the frozen Code - OSS agent host showed:

  agentHostTerminalManager._spawnPty
    -> node-pty.spawn
    -> WindowsTerminal
    -> WindowsPtyAgent
    -> ConoutConnection
    -> Worker

The conout worker was stopped in the Node inspector startup message loop while processing Debugger.enable. Five seconds later, the agent-host event loop thread entered the WindowsPtyAgent timeout fallback and proceeded through conptyNative.connect() into NtFsControlFile/ConnectNamedPipe. Since the paused worker had not connected the output side, ConnectNamedPipe waited synchronously and blocked the event loop. Consequently, CDP's Runtime.enable request could not complete and the debugger attachment appeared frozen.

The worker-ready handshake was originally introduced to prevent this deadlock in #885, but a later timeout fallback called connect() anyway to avoid leaving the PTY in a zombie state. That fallback violated the handshake invariant and restored the blocking path under debugger induced worker delays.

Make worker readiness a hard prerequisite for calling connect():

• Fail and clean up the pending PTY when the readiness watchdog expires instead of attempting the native connection.
• Propagate worker startup errors and premature exits to WindowsPtyAgent.
• Kill the pending native PTY, dispose the worker, destroy its sockets, and report the failure through onError.
• Clear the watchdog after readiness, connection failure, or explicit kill.
• Ignore readiness and error events arriving after timeout or termination.