codemode: three defects the A/B benchmark found in the decompiler path

Benchmarking the port against master op-by-op (rather than only asking whether
tests pass) turned up three real bugs, all in the most user-visible path:
opening pseudocode.

1. decompile was doing decomp_map's job. It called the full per-column line
   map purely to fill in each line's /*0xEA*/ anchor. The tool ida-tui was
   written against takes ONE get_line_item at column 0 per line; the port took
   one per COLUMN, i.e. thousands of get_line_item+dstr() calls per function
   instead of one per line. Every pseudocode open cost the same as opening the
   split view. Carried the real implementation over: 1888ms -> 53ms.

2. decomp_map used the pre-optimisation line map. Ours memoises obj_id -> ea
   for the whole function (commit 853d90c: dstr() was 79% of the tool, and
   consecutive columns report the same ctree item), the port's did not.
   1925ms -> 287ms.

3. _idatui_compact imported ida_pro_mcp on every call. Under Code Mode that
   package is not installed in the database process, so the import failed every
   time -- and a FAILED import is never cached, so each one re-searched the
   whole of sys.path: 422 failed imports per pc_nums call, which was most of
   its runtime. 1428ms -> 257ms.

   The same bug was a correctness bug hiding behind the perf bug: the fallback
   path collapsed whitespace INSIDE string literals, where the real function
   preserves it. Pseudocode columns are served in those coordinates, so on any
   line containing a string with two spaces, every literal's mark and every
   reformat would have been placed on the wrong column. It never fired on
   master because ida_pro_mcp is installed there. Now calls the byte-identical
   module-level shim directly, with the deviation from the extracted original
   documented in place.

Narrow verification: decomp/split_view/opfmt/follow/comment/structs scenarios,
72 passed, 0 failed. Full gate running separately.

0 files changed, 0 insertions, 0 deletions