Add start_debugging_with_config tool for inline-config launches

[ksa-real]

Summary

Adds a language-agnostic start_debugging_with_config tool that lets an agent start a debug session from a raw, caller-supplied DebugConfiguration — no launch.json entry required.

The existing start_debugging tool launches a named configuration that must already exist in the workspace's launch.json. That's a hard blocker for the common agent workflow of "debug this arbitrary program/command right now," and it forces users to hand-edit launch.json for one-off sessions.

This tool forwards the config straight to vscode.debug.startDebugging, keeping the extension a thin shim while the caller owns all toolchain/runtime specifics:

• TypeScript: { "type":"node", "request":"launch", "program":"<abs .ts>", "runtimeExecutable":"tsx" }
• Python: { "type":"python", "request":"launch", "program":"<abs .py>" }
• Attach: { "type":"node", "request":"attach", "port":9229 } (e.g. a node --inspect-brk process)

Adapter-specific fields (args, env, cwd, console, port, stopOnEntry, …) are passed through unchanged. Minimal validation only: type and request are required; name defaults when omitted.

Tests

startDebuggingMatrix.test.ts covers:

• config forwarded verbatim (no fields injected or stripped)
• clean run returns terminated
• missing name is defaulted rather than failing
• missing type and invalid request are rejected
• a failed launch is surfaced

Notes

• No version bump / package.json change — implementation + tests only.
• Rebased on current main (includes Fix MCP connection errors, slow stepping, and stale debug state #96 and Ozzafar/handle session termination #97); the two commits here are the tool and its tests.

[ksa-real]

Concern: the loopback server is unauthenticated

Not specific to this PR, but it broadens the blast radius so worth raising here.

Loopback binding + Host/Origin checks block remote and browser (DNS-rebinding) access, but nothing authenticates the endpoint itself — the trust boundary is just "can open 127.0.0.1:3001." So any local process (or any user on a shared host) can drive the full tool surface without credentials, and that surface is code execution by design: start_debugging_with_config launches an arbitrary runtimeExecutable/command, start_debugging runs workspace code, evaluate_expression evals in the debuggee. Net effect: unauthenticated local RCE in the user's context — and fully network-exposed if debugmcp.bindHost is ever set non-loopback (only a console warning guards that).

Mitigation (standard path, not bespoke). The server must stay in the extension host (it needs vscode.debug.*), so a stdio transport isn't an option here — even McpStdioServerDefinition spawns a separate child process with no access to the debugger. But the documented HTTP-auth model fits: require a per-session bearer token.

• VS Code / Copilot: supply it via McpHttpServerDefinition + resolveMcpServerDefinition, where the editor injects the Authorization header (docs).
• Cursor / Codex / Claude (no provider API): write the same token into the MCP config the extension already generates.

[ksa-real]

Follow-up to my note above: there's now a working implementation of the per-install bearer-token approach on feat/mcp-auth-token.

What it does:

• The HTTP server requires a per-install token (randomUUID, persisted in SecretStorage). Any request with a missing/invalid token gets 401 (constant-time compare; token accepted via Authorization: Bearer header or ?token= query param).
• The token is delivered to the editor's built-in MCP client automatically, so no manual config:
  • VS Code / Copilot: McpHttpServerDefinition + resolveMcpServerDefinition (editor injects the Authorization header).
  • Cursor: vscode.cursor.mcp.registerServer, with the token carried in the URL query to work around Cursor's known dropped-headers bug (header is still sent for when the upstream fix lands).
  • Other agents: the same token is written into the MCP config files the extension already generates.
• debugmcp.bindHost warning updated to reflect that the server is token-gated but still widens the attack surface off loopback; added tests for the 401 path and token extraction.

Verified end-to-end in Cursor (registers via the extension API, unauthenticated/wrong-token requests return 401, valid token drives the full tool surface). Happy to open a PR if there's interest.