[FEATURE] DAP mirror: let an IDE attach to an agent-owned debug session with shared pause state

[debugmcpdev]

🚀 Feature Request

The workflow this enables

An agent debugs a process that no IDE owns — in CI, in a container, on a remote host, or driven from a plain terminal — parks it at an interesting point, and a human then attaches their IDE (VS Code or any DAP client) to inspect the live, paused state: walk the actual stack, evaluate expressions, examine real objects. Strictly better than a core dump or logs.

Originally requested in #7 ("connect VS Code to a Python session started from MCP"). For users who already have VS Code open, that literal ask is now best served the other way around — run the session in VS Code and let the agent drive it via VS Code's agent-debugging/MCP surface. This issue tracks the scenario that inverted flow structurally cannot cover: sessions that originate where no IDE exists.

Motivating scenarios

• CI flake triage: the agent reproduces a flaky test under the debugger, catches the failure live, and holds the process paused; a human attaches remotely in the morning and inspects the actual failing state.
• Long-running process babysitting: an agent attached to a staging service overnight notices an anomaly, pauses at it, and hands a human the live session.
• Terminal / chat-driven users: someone debugging via an agent with no editor session at all occasionally wants to drop into an IDE for a look around, without restarting the run.

Why this doesn't work today

1. Each launch-mode session spawns its adapter on a private ephemeral localhost port (e.g. python -m debugpy.adapter --host 127.0.0.1 --port <ephemeral>) with mcp-debugger as the sole DAP client — there is no socket an IDE could reach.
2. Debug adapters are generally single-client (debugpy explicitly so); a second simultaneous DAP client isn't something we can configure around.
3. Sequential hand-off exists in attach mode (agent attaches to a debugpy --listen process, detaches, human attaches) but the pause doesn't survive the swap — on disconnect the debuggee resumes, which loses the "parked at the interesting point" state that is the whole value.

Proposed direction: a DAP mirror

mcp-debugger already sits mid-stream as a DAP client. It could additionally expose a DAP server endpoint per session that an IDE connects to, multiplexing both clients onto the single live adapter session:

• Forward stopped/continued/thread/output events to both clients; the paused frame is genuinely shared.
• Reconcile request IDs and route responses to the requesting client.
• Mediate breakpoint ownership (union of both clients' breakpoints, or agent-owned with IDE additions).
• Per-client capability negotiation (the IDE's initialize is answered from the session's known capabilities).

Open questions

• Read-only mirror first (inspection only: stack/scopes/variables/evaluate) vs. full dual-control from day one — read-only sidesteps most of the ownership/reconciliation complexity and covers the motivating scenarios.
• How the endpoint is exposed and secured (DAP sockets are unauthenticated; localhost + user-initiated expose tool call, with the same port-forward guidance as remote attach).
• Per-adapter quirks (js-debug child sessions, Java JDI bridge).

📊 Impact

• Who would benefit: anyone combining agent-driven debugging with human inspection outside the IDE-owned flow
• Priority: Medium
• Complexity: Large