Merge the IDA Code Mode port

Replaces the private idalib worker (idatui/worker.py + worker_client.py, with
server/patch_server.py injecting tools into ida-pro-mcp) with an ordinary
client of ida_codemode.client.DatabaseHandle. A database open by an IDA GUI is
reused; otherwise Code Mode starts or shares a managed idalib worker. The TUI
no longer owns an IDA process, and closing it releases only its lease.

Based on Duncan Ogilvie's port, rebased onto ~150 commits of local work it
predated. The rebase itself was mechanical; landing it was not. Nine defects
had to be fixed before the feature set was whole again, none of which the
patch's own tests could catch:

  - DatabaseHandle.open() takes image_base, not loading_address: every
    connect() would have raised TypeError on the first call
  - five operations our tree had grown were simply missing (flowchart, so the
    graph view was dead; op_format/pc_nums/pc_num_format, so 'o'/'O' were;
    survey_binary)
  - set_comments wrote only the disassembly comment, so comments never
    appeared in pseudocode
  - xref_query returned rows in raw IDA order, and 'follow the call' silently
    followed the fall-through instead
  - rename accepted one edit per category, so bulk symbol import was dead
  - decompile ran decomp_map's full per-column ctree sweep to fill in a
    per-line address anchor
  - heads shipped without operand extents or the digest protocol
  - the package became unimportable without ida_codemode installed, which
    killed the offline test suites

Verified against the pre-codemode tag rather than against assumptions: the
full suite is 788 passed / 0 failed, and the pilot's 301 checks match the old
backend exactly. Performance is within 2x on the listing hot path and faster
on decompile, disasm and connect, after fixing two runtime costs that are
documented for upstream in docs/CODEMODE_UPSTREAM.md.

Test runtime came down from ~9m20s to 115s along the way -- not by removing
checks, but by removing four kinds of waiting-on-a-guess that were also
hiding real failures.

1 files changed, 10 insertions, 2 deletions

diff --git a/tests/test_trace_ui.py b/tests/test_trace_ui.py
index bb016eb..5844c90 100644
--- a/tests/test_trace_ui.py
+++ b/tests/test_trace_ui.py
@@ -20,6 +20,7 @@ sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)))
 from textual.widgets import Input, OptionList, Static  # noqa: E402
 
 from _fixtures import staged  # noqa: E402
+from idatui._sync import settle  # noqa: E402
 from idatui.app import (DecompView, IdaTui, ListingView,  # noqa: E402
                         RegWriteScreen, TraceDock)
 
@@ -109,13 +110,20 @@ async def run() -> int:
             lst.focus()
             await pilot.pause(0.4)
             await pilot.press("]")
-            await wait(lambda: app._t == 1, pilot, 20)
+            # `app._t` is assigned the moment the key is handled, so it is NOT a
+            # signal that the VIEW has followed -- the navigation it kicks off
+            # runs in a worker. Waiting on it and then reading the cursor was a
+            # race that the (slower) Code Mode backend loses. Gate on the thing
+            # the check is about.
+            await settle(app, lambda: app._t == 1 and lst._cursor_ea() == t.ip(1),
+                         timeout=20)
             check("] steps forward one instruction", app._t == 1, f"t={app._t}")
             check("the code view follows the trace",
                   lst._cursor_ea() == t.ip(1),
                   f"{lst._cursor_ea()} vs {t.ip(1)}")
             await pilot.press("[")
-            await wait(lambda: app._t == 0, pilot, 20)
+            await settle(app, lambda: app._t == 0 and lst._cursor_ea() == t.ip(0),
+                         timeout=20)
             check("[ steps backward", app._t == 0, f"t={app._t}")
             await pilot.press("[")
             await pilot.pause(0.4)