[BUG] start_debugging hangs past 60s for a fast-crashing JavaScript script

[debugmcpdev]

Bug

start_debugging for a JavaScript script that crashes almost immediately after launch (e.g. an uncaught throw from a ~100ms timer callback) sometimes never resolves — the MCP call times out at 60s. startDebugging's waitForReady has a 30s cap and listens for terminated/exited/exit, so the hang is upstream of it — likely the js-debug launch orchestration (launch barrier / child-session adoption) racing the debuggee's death: the child target dies while adoption is in flight and whatever the parent launch request is awaiting never settles.

Meanwhile the session itself reaches state: 'stopped' correctly (the proxy worker logs a complete shutdown sequence ~2s after launch) — only the start_debugging response is stuck.

Repro (verified on main @ 2a93227)

// crash.js
function boom() { throw new Error('js uncaught exception'); }
setTimeout(boom, 100);

1. create_debug_session (javascript)
2. start_debugging crash.js with dapLaunchArgs: { stopOnEntry: false }
3. The call sometimes returns after ~17s with state: 'stopped' (readiness-window timeout), sometimes hangs past the 60s MCP client timeout. Racy — depends on crash timing vs. child adoption.

Impact

An agent debugging a crashing Node script without breakpoints gets a hung tool call instead of a prompt "terminated" result. Found while validating #220 (break-on-exception): the with-breakOnExceptions path is unaffected because the session pauses at the exception before the debuggee can die.

Expected

start_debugging resolves promptly (well under the readiness cap) when the debuggee terminates during launch, regardless of js-debug child-session adoption state.