fix: handle inspector session leak on Profiler.enable/start failure

[buley]

Summary

enableCPUProfiler in src/compiler/sys.ts calls session.connect() but the callbacks for Profiler.enable and Profiler.start ignore the error parameter. If either V8 API call fails, the inspector session is never disconnected.

Bug verification

1. session.connect() is called at line 1657
2. session.post("Profiler.enable", callback) -- callback signature is (err, result) but err is ignored
3. If Profiler.enable fails (e.g., profiler already active), activeSession is never set
4. disableCPUProfiler checks activeSession before calling session.disconnect() -- it will never find the leaked session
5. The session stays connected until process exit

Fix

Add error parameters to both callbacks. On failure, disconnect the session immediately and invoke the continuation callback so the caller is not left hanging.

Found by Gnosis Polyglot Scanner, an open-source static analysis tool that detects resource leaks across languages via topological analysis of control flow graphs.

Signed-off-by: Taylor Buley taylor@forkjoin.ai

[Copilot]

Pull request overview

This PR fixes a resource leak in the Node.js CPU profiler integration by ensuring an inspector.Session is disconnected when Profiler.enable or Profiler.start fails, preventing a connected session from lingering until process exit.

Changes:

• Handle the err parameter in session.post("Profiler.enable", ...) and disconnect on failure.
• Handle the err parameter in session.post("Profiler.start", ...) and disconnect on failure.
• Ensure the continuation callback is still invoked on error so the caller proceeds.

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate