disasm: render opcode bytes (toggle 'o'), padded to widest insn

Fetch per-instruction opcode bytes alongside the disasm listing and show
them in a column between the address and the mnemonic. Instruction length
comes from consecutive addresses (variable-length safe: x86 movabs shows
its full 10 bytes); the block over-fetches one instruction for the last
line's boundary, falling back to the function end for the final insn.

The column pads to the widest instruction across the whole function:
_fetch_block tracks a running max, and on load a background scan_bytes()
settles a stable width so padding doesn't jump as blocks stream in.
_op_field is shared by the rendered strip, _line_plain, and search _fmt
so cursor/match offsets stay aligned. 'o' toggles the column.

1 files changed, 20 insertions, 0 deletions

diff --git a/plan/rpc.md b/plan/rpc.md
new file mode 100644
index 0000000..1f6b119
--- /dev/null
+++ b/plan/rpc.md
@@ -0,0 +1,20 @@
+## RPC functionality
+
+we need some way to drive an instance of our IDA tui programatically,
+with all UI interactions actually being shown as if a regular user was driving
+the software.
+
+the rationale is we'll be doing some machine-assisted reverse engineering
+and livestreaming the work/progress on our little terminal streaming platform, 
+sl0p.foo !
+
+come up with a plan on how to architect this, remember the machine (you, the LLM)
+that will eventually be driving our TUI is running inside a tmux pane.
+I think it'd be most sensible if you assume we run the TUI in some kind of rpc/server
+mode in a second pane and talk to it over unixsocket/tcp. 
+
+I think we want some "highlevel" RPC primitives for UI actions, but also a
+more raw RPC primitive that lets us send "keystrokes" to the TUI. 
+
+carefully go through our current architecture and the requirements I vaguely
+sketched out above and propose an implementation.