[Feature]: Integrated visual debugger with breakpoints (IntelliJ / VS Code-style)

### Problem or use case

Summary
Add a first-class visual debugger to Orca — set breakpoints in the gutter, step through code, inspect variables, and view the call stack — similar to the debugging experience in IntelliJ IDEA or VS Code. Today Orca is excellent at orchestrating agents and editing code, but when an agent's output doesn't work, the only way to debug is dropping to the terminal and running node --inspect, pdb, dlv, etc. manually. A native debugger would close the loop between writing code (agents) and verifying it (humans) without leaving the app.
Motivation / Problem

Orca already embeds VS Code's editor, integrated terminals, and per-worktree isolation. The one big IDE capability missing is interactive debugging.
When reviewing or fixing agent-generated diffs, I frequently need to step through the code to understand why it behaves a certain way. Right now that means switching to a separate IDE (IntelliJ/VS Code), which defeats the purpose of a single ADE.
Parallel worktrees make this even more valuable: being able to attach a debugger to a specific worktree's process would let me compare the runtime behavior of two agent variants side by side, not just their diffs.

### Proposed solution

Proposed UX
Model it closely on VS Code / IntelliJ so it feels familiar:

Breakpoints — click the editor gutter to toggle; support conditional breakpoints, hit counts, and logpoints.
Execution controls — Continue, Pause, Step Over, Step Into, Step Out, Restart, Stop.
Variables & Watches — inspect locals/globals in the current frame; add watch expressions; edit values inline.
Call Stack — navigate frames, jump to the corresponding source line.
Debug Console / REPL — evaluate expressions in the paused context.
Run/Debug configurations — a launch.json-style config (reusing the VS Code schema would be ideal for zero learning curve), scoped per worktree.
Per-worktree debug sessions — each worktree can run its own independent session, consistent with Orca's isolation model.

Technical notes

Since Orca is built on VS Code's editor and is TS/Electron, the most direct path is to implement the Debug Adapter Protocol (DAP) — the same protocol VS Code and many other tools already speak. That gives access to a large ecosystem of existing debug adapters (js-debug for Node/Chrome, debugpy for Python, Delve for Go, CodeLLDB for C/C++/Rust, etc.) instead of writing per-language integrations from scratch.
Reusing the launch.json schema would let users bring existing configs and lower the barrier to adoption.
Stretch goal: expose debug control to agents via the Orca CLI (e.g. orca debug start, set-breakpoint, step), so an agent could set a breakpoint, run to it, inspect state, and self-correct — a genuinely differentiated capability for an agentic IDE.

### Alternatives or additional context

Alternatives considered

Keep using the terminal (node --inspect, pdb, dlv) — works today but is manual, has no gutter breakpoints or variable inspection, and forces a context switch.
Debug in an external IDE — defeats the single-ADE value proposition and loses the worktree context.

Additional context
Priority order that would already be very useful if the full scope is too large: JS/TS (Node + Chrome) first, then Python, given they're likely the most common stacks among Orca users.