MSIM-560 the emulators hold the chip, and radioserver is gone

[A13xB0]

An emulated node ran in two processes: the emulator, and a radioserver that
owned the SX1262 and forwarded SPI to it over a socket. The chip moved into
MeshBench/virtual-sx1262, and
both emulators now load it directly. That leaves one process per node and
one socket, to the RF engine, which is genuinely elsewhere because the channel
is shared with every node in the scenario.

	before	after
processes per emulated node	2	1
SPI	a socket round trip per clocked byte	a function call
DIO1	polled at 1 kHz	pushed by the chip
protocol implementations	4	2

What the socket cost, beyond the round trips

• It framed SPI a byte at a time, a path less exercised than the buffered
  one. That is how GetRssiInst came to answer correctly for a native node and
  zero for an emulated one for months, which is where the firmware takes its
  entropy: every emulated board derived its identity from a constant.
• DIO1 could only be polled, because the protocol was request-response. A
  millisecond is a long time to hold a receive interrupt, and a packet delivered
  and acknowledged inside one sampling gap raised the pin never.
• It put three clocks in three processes in front of anybody asking what
  happened when.

Renode's peripheral

Rewritten around the library it loads, in three files because one was 548 lines
and the limit is 500: the loader and the ABI, the line to the engine, and the
pins and SPI the firmware can see.

It resolves the library by path from MESHBENCH_RADIO_LIB and binds each
entry point through dlopen/LoadLibrary plus
Marshal.GetDelegateForFunctionPointer, rather than by DllImport name. Renode
may be running on Mono or on .NET and NativeLibrary's resolver is not on both;
a name would also need a library search path set three different ways for a file
whose location we already know.

Two things found on the way

• A release bundle never carried Renode's platform descriptions or our own
  peripherals, so an nRF52 board could not start from one at all. Fixed here,
  because it sits inside making bundles work: SupportDir() looks beside the
  binary first, every bundle copies them there, and verify-bundle.sh refuses a
  bundle without them.
• heltec_t096 carries a front-end module and no .repl wires its pin, so
  its FEM reports as never switched in. Unchanged by this and said out loud at
  the call site rather than half-fixed; wiring it means a pin per board profile,
  read from each variant.

Measured

One board at a time on an idle machine, with no radioserver process in
either run. Every row of the board probe passes:

board	emulator	flood
Generic_E22_sx1262	QEMU, chip via GModule	passed, 2 of 2
RAK_4631	Renode, chip via dlopen	passed, 2 of 2

Merge order matters

This must not merge before a QEMU release carrying the new device exists and
QEMU_RELEASE names it. The pinned v9.2.2-meshbench-sx1262-10 still has the
socket device and does not know radio-bridge, so anyone who fetches QEMU
rather than building it would get a machine that refuses to start.

1. merge MeshBench/qemu#18
2. cut the QEMU release, move QEMU_RELEASE and its digests here
3. merge this

MeshBench/meshcore-native#18
retires radioserver at the source and is independent of the order above.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6