app: --backend {mcp,worker} — run the TUI on our idalib worker (migration step 3)

Wires WorkerClient into the app as a selectable backend, so you can launch:

    ida-tui --backend worker /path/to/binary        # or IDATUI_BACKEND=worker

* IdaTui gains a `backend` param. _connect is refactored into _open_mcp_client()
  (the existing ida-pro-mcp path, unchanged) and _open_worker_client() (spawns a
  private idalib worker via WorkerClient that opens+analyzes THIS binary and
  streams progress into the loading overlay). The common tail (health, keepalive,
  Program, load_functions) is shared, so domain.py and every view are untouched.
* _reconnect branches the same way: a dropped worker (segfault → closed socket)
  respawns a fresh WorkerClient — the connection-loss recovery already built
  works verbatim for the worker.
* launch.py adds --backend (env IDATUI_BACKEND); the worker path skips all the
  supervisor/server plumbing (it owns a private worker) and just sweeps stale
  locks + requires a binary. keepalive is a no-op for the worker (it never idles
  out). mcp remains the default — nothing changes unless you opt in.

Verified without idalib: all four files parse; --backend is in --help; IdaTui
constructs for both backends with both openers present; WorkerClient covers the
full client surface. The idalib E2E (experiments/worker_smoke.py, and actually
launching --backend worker) still can't run in this sandbox — it now reaps every
idalib spawn before a byte is written — but the mcp default is untouched and the
worker path reuses proven pieces (the unix protocol benched at ~50us/call; the
worker dispatches the same tool functions the HTTP path does).

To validate on a real box: ida-tui --backend worker targets/echo   (or run
experiments/worker_smoke.py for the headless read-path check).

0 files changed, 0 insertions, 0 deletions