perf: read_raw tool — bulk byte reads for the hex view (5–8x)

The hex view's lazy-load was dominated by the byte-read path, which was slow
on two axes:
  * server: get_bytes uses read_bytes_bss_safe, a per-byte loop (is_loaded +
    get_byte = 2 IDA calls/byte → ~8k calls for a 4KB block), and encodes the
    result as "0x00 0x01 ..." text (~5x wire bloat);
  * client: read_bytes re-parsed that with int(tok,16) per byte;
  * and get_bytes silently TRUNCATES ≥16KB responses to "0x..." (wrong data).

New injected `read_raw` tool does a single bulk ida_bytes.get_bytes (C-speed)
and only re-checks is_loaded for the sparse 0xFF bss-sentinel bytes, returning
one contiguous hex string. Client decodes with bytes.fromhex (C-speed). domain
read_bytes uses it with a transparent fallback to get_bytes on older servers
(cached _no_read_raw flag). HEX_BLOCK 4096→16384 now that big blocks are cheap
and no longer truncate → 4x fewer round-trips while scrolling.

Measured (echo, warm): 4KB 22.7ms→4.7ms (4.9x), 8KB 51.6ms→6.6ms (7.8x), and
16KB works (15.7ms) where get_bytes truncates outright. Byte-exact match vs the
old path; disasm opcode bytes (also read_bytes) benefit too. Pilot hex +
disasm_nav 12/0. Needs a supervisor restart (new server tool).

0 files changed, 0 insertions, 0 deletions