[AUTOMATED] fix(ghidra): fetch p-code injects from the host instead of failing the function

[mahaloz]

The problem

With kuna installed as Ghidra's decompiler core, most ARM and MIPS functions
produce nothing at all: six of fmt_arm's seven functions and plt_mips32/main
come back with an empty payload, which Ghidra reports as a decode error.

$ GHIDRA_INSTALL_DIR=<ghidra> \
  KUNA_GHIDRA_EXE=decompiler/target/release/kuna_ghidra \
  KUNA_SMOKE_BINARY=decompiler/crates/kuna-analysis/tests/fixtures/fmt_arm \
  KUNA_SMOKE_FUNCTIONS=main \
  python3 integrations/ghidra/live-smoke/kuna_vs_stock.py
main: completed=False  err='Pcode: Decoding error: Expecting <doc> but did not scan an element'

kuna's own warning on that run names the cause: could not decompile the function at r0x00000504 (inject_userop: callother-fixup template not compiled). Ghidra mode has no local .sla, so no <callotherfixup> body is
ever compiled, and ARM.cspec's setISAMode — raised by every interworking
BX/BLX — fails the whole function. All nine vendored MIPS cspecs declare the
same fixup. The same functions decompile fine on the CLI, where the template
exists.

The fix

• When the injection library holds no compiled template, the two consumers in
  decompile_drive.rs fall through to a new defaulted
  EngineTranslate::fetch_inject_pcode, which the ghidra translator answers
  with a getPcodeInject query — the same seam shape as
  probe_register_varnode.
• The response is streamed straight into the emitter and never cached. It is
  p-code the host has already lifted against one call site: two answers for the
  same setISAMode differ in both the fall-through offset and the <addr>
  stamped on every op, so keying a cache by payload id would silently
  miscompile any body that uses inst_start/inst_next/the call address.
• A host exception is caught and re-raised as a low-level error naming the
  payload, as upstream does, so the warning says which injection failed instead
  of repeating the host's bare text.
• No option: this only corrects wrong output. The standalone path keeps the
  identical template arm and its C is byte-for-byte unchanged; ghidra mode goes
  from failing the function to the CLI's answer. A flag would also be
  unreachable from the GUI, which is where the affected user is.

The tests

tests/inject_e2e.rs drives the six failing ARM functions plus frame_dummy,
MIPS main, and AArch64 (whose cspec declares no fixup) through the ghidra-sim
harness; without the fix six of seven ARM and the MIPS function come back with a
0-byte payload. Each drive also pins the getCallOtherFixup traffic, so a
degrade that emitted a placeholder without touching the wire would fail. Two
more cover the host declining, by exception and by empty response. In
protocol_e2e.rs, a round trip over bytes captured from a live Ghidra 12.1.2:
the request kuna builds is byte-identical to the one Ghidra received, and
Ghidra's own response decodes to the r0 = r0 fixup body. kuna decompile fmt_arm <fn> is unchanged on all seven functions.

Closes #407.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TzfafnkDMQiYoifXP5HSC8