Port to the ida-codemode 0.5.3+ public API

0.5.x turned ida_codemode.__all__ into a real public API and hid the rest:
client.py -> handle.py, registry.py -> _registry.py + instances.py,
resolver.py -> _resolver.py. Every import we had was from a module that no
longer exists, so the TUI could not attach at all.

  - handle.entry            -> handle.instance (RegistryEntry -> DatabaseInstance)
  - 30 keyword-only options -> DatabaseOpenOptions(...) passed as options=
  - IdbBusy                 -> DatabaseBusyError
  - InstanceDisconnected/ClientError -> DatabaseDisconnected/CodeModeConnectionError
  - our scan_instances()+idb_key() ownership walks -> find_database_owner()
  - our FileLock poking (_wait_for_entry_release)  -> wait_database_released()
  - registry.discover_instances() -> discover_databases() + InstanceState

_database_exists() is deleted with it: upstream now drops the loader switches
itself when reopening an existing IDB (_resolver._build_worker_command), which
is the same fix we had client-side. See docs/CODEMODE_UPSTREAM.md section 4 for
the one invocation that still slips through.

The offline contract suite has to keep running under a stdlib-only python3,
where every Code Mode name is bound to None -- so it now injects a strict fake
DatabaseOpenOptions and a real DatabaseBusyError exception alongside the fake
handle. Without the latter, `except DatabaseBusyError` is `except None`, and
the TypeError it raises masks whatever actually failed inside the try. The
loader-option names moved inside the options dataclass, so the guard that
caught `loading_address` vs `image_base` moved with them
(_option_fields_are_real).

uv.lock pins 0.6.1; ~/ida-venv and .venv are on 0.6.1 with the ida-domain
0.5.1 / zeromcp 1.8.0 floors it requires. Full gate: 1065 passed.

0 files changed, 0 insertions, 0 deletions