Rebase MISTER EXO's ida-codemode port onto the current tree

Mechanical part of the port: the 27-file patch was cut against a base ~148
commits behind us, so it did not apply. Resolved 11 conflicts (all of them
diff drift, not semantic clashes) and the three file deletions:

- app.py: the patch re-inserted _do_rename/_do_name_addr/_seek_split etc. as
  "theirs" because our tree moved them to edit_ctl.py/trace_ctl.py. Kept ours
  and applied the real intent (WorkerClient->CodeModeClient, .call->.invoke,
  _open_worker_client->_open_database_client) at their current homes.
- domain.py: kept Head as a NamedTuple -- the patch reverted it to a frozen
  dataclass, which the perf work measured at 2.9us vs 1.9us per row on a
  quarter-million-row walk. Dropped _fetch_output (no download_url under Code
  Mode) and its now-dead urllib/json imports.
- pane.py: the patch's deletion swallowed our zellij support along with the
  worker-reaping block it meant to remove. Kept zellij, removed the reaping.
- test_scenarios.py: the idb_save->save_database teardown hunk belongs to
  tests/_fixtures.py in our tree; applied it there and kept our pc_num_format
  scenario that the drift landed on.

Three defects in the patch itself, fixed here:

- It made "import idatui" hard-require ida_codemode, so every offline suite
  died at import -- including the pure ones (graph/index/trace) that are the
  house rule for "tests/run.py --fast". The import is now deferred and gated
  on the binding, which is also what lets the port's own contract tests
  inject a fake DatabaseHandle.
- project.stage() inlined an ida_codemode.registry import and treated "library
  not installed" as "someone owns this database", which broke IDA-free project
  staging. Ownership lookup moved to codemode_client.database_owner().
- tests/test_codemode_client.py had no NEEDS_IDA marker, which tests/run.py
  rejects outright.

Offline suite: 301 passed, 0 failed. Against master's 344 the whole delta is
accounted for: -40 worker_client (module deleted), -18 launch sweep checks
(behaviour deliberately removed) +3 guarding that it stays removed, +2 pool
(GUI-save semantics), +13 new codemode_client contract tests.

NOT yet done, and the port is not functional without it: the adapter is
missing five operations our tree grew since the patch's base (flowchart,
op_format, pc_nums, pc_num_format, survey_binary) and its "heads" predates
back-walking and digest/expect.

1 files changed, 21 insertions, 27 deletions

diff --git a/docs/PAGING_FINDINGS.md b/docs/PAGING_FINDINGS.md
index bcde583..bd6c38f 100644
--- a/docs/PAGING_FINDINGS.md
+++ b/docs/PAGING_FINDINGS.md
@@ -2,10 +2,10 @@
 
 Measured against a real target: `libcrypto.so.3` (5.7 MB, **10,092 functions**,
 biggest function **52,120 instructions**). These constraints drive the domain /
-paging layer. They describe the ida-pro-mcp *tool functions* (`list_funcs`,
-`disasm`, `decompile`, `xref_query`, …) which the idalib worker now calls
-in-process (`idatui/worker.py`) — the shapes and caps below are the tools'
-behaviour and are unchanged by dropping the HTTP transport.
+paging layer. The measurements below came from the former ida-pro-mcp tool
+backend. The Code Mode port preserves the adapter response shapes and conservative
+page sizes, but executes enumeration through ida-domain; old server caps and RTT
+numbers are historical rather than Code Mode constraints.
 
 ## Response shape (list_* / *_query tools)
 
@@ -93,32 +93,26 @@ disasm totals are **top-level** fields, not under `asm`:
 (correct). The pseudocode view must handle "decompilation failed" gracefully —
 fall back to the disassembly view or show an error panel.
 
-Normal decompile bodies are server-truncated with a `[N chars total]` marker
-(still to be solved for full-body display — see Phase 2).
+Code Mode returns the complete execution result directly; ida-tui no longer
+needs MCP structured-content/download-URL recovery for large pseudocode bodies.
 
-## Worker lifecycle (idatui's own idalib worker)
+## Code Mode lifecycle
 
-idatui no longer uses ida-pro-mcp's shared HTTP supervisor. `idatui/worker.py`
-opens exactly **one** database with `idapro.open_database(...)` in its own process
-and serves tool calls over a unix socket (`WorkerClient`). Consequences vs the
-old supervisor model, which several design choices here were built around:
+`CodeModeClient` owns an authenticated SSE lease on a registered database:
 
-* **No `max_workers` cap, no cross-session contention.** Each TUI owns its
-  worker; there is no "Maximum idalib worker count reached" and no shared license
-  slot to free.
-* **No idle self-exit / keepalive dance.** The old per-worker `WorkerLifecycle`
-  watchdog (`idle_ttl_sec`, default 600s) and the `KeepAlive` heartbeat that
-  fought it are gone with the supervisor. The worker lives as long as the TUI
-  holds the socket and dies with it. `WorkerClient.keepalive()` is a no-op kept
-  for API parity, and `--ttl` is passed through but the single owned worker does
-  not self-reap.
-* **A crashed worker drops the socket**, surfacing as `IDAConnectionError`; the
-  app's `_reconnect` respawns a fresh worker (re-opening + re-analyzing the
-  binary). The hard-kill lock recovery below still applies.
+* A matching GUI is preferred and remains open when the TUI exits.
+* Otherwise Code Mode reuses or starts a shared managed idalib worker.
+* Releasing one lease never terminates another client's session. A managed
+  worker saves and exits after its final lease under Code Mode's grace policy.
+* Lease loss surfaces as `IDAConnectionError`; reconnect performs discovery
+  again and may bind a newly-created instance. It does not silently swap the
+  handle underneath an operation.
+* `--ttl` and the old keepalive flag are compatibility no-ops; the lease itself
+  carries heartbeats.
 
 ## Writable path requirement (operational)
 
-`idb_open` writes the `.i64` next to the input binary, so the path must be
-**writable**. Opening from read-only dirs (e.g. `/usr/lib`) fails with
-`"Failed to open database"`. Copy targets into a writable dir first
-(`targets/` in this repo).
+Attaching to a registered GUI does not require ida-tui to write beside the input.
+Creating a managed database does require a writable output path. Multi-binary
+projects provide one in their sidecar. ida-tui does not sweep IDA scratch files,
+because another registered session may own them.