feat: add noWait parameter to start_debugging and continue_execution

[ankitajha6475-jpg]

Description

Historically, DebugMCP's \start_debugging\ and \continue_execution\ calls blocked synchronously until a breakpoint was hit. If an AI agent invoked \start_debugging\ before informing the user in text, the turn blocked in a tool-call wait state, preventing the user from receiving the prompt instructions.

This PR natively updates \microsoft/DebugMCP\ to support
oWait: true.
The agent can now call \start_debugging(noWait: true)\ to arm the debugger in the background and immediately get control back to output instructions to the user.
The human user can then safely interact with the UI at their own pace. Once the breakpoint is reached, the IDE natively pauses execution and the agent can evaluate expressions.

[ankitajha6475-jpg]

@microsoft-github-policy-service agree

[Oz Zafar (ozzafar)]

ankitajha6475-jpg Thanks for adding this! Please address the following:

1. Remove unrelated generated changes from AGENTS.md, CLAUDE.md and package-lock.json.
2. Keep this PR scoped to the noWait parameter: get_debug_state should be proposed separately unless the PR description explains and tests that API addition.
3. Add direct tests proving start_debugging({ noWait: true }) returns without waiting for a stop/termination, continue_execution forwards noWait across multi-window routing, and continue_execution({ noWait: true }) does not perform state-change waiting.
4. Update the DebuggingHandler architecture documentation to describe the opt-out behavior.