fix: switch UEFI boot to snponly

[mwennrich]

Description

Use snponly.efi instead of full ipxe.efi, so iPXE stays aligned with the firmware-selected PXE interface and avoids getting stuck on the virtual device.

Closes #47

[majst01]

Claude says this regarding the change from ipxe to snponly:

Both are iPXE builds for UEFI, but they differ in how they talk to the network card.

ipxe-x86_64.efi (native drivers)

• iPXE includes its own set of NIC drivers (ported from Linux/gPXE-era drivers) and uses them directly, bypassing the UEFI firmware's own network stack once it takes over.
• Because it's driving the hardware itself, it gets iPXE's full feature set: things like more efficient TCP/HTTP(S) handling, iPXE-specific timing/retry behavior, and consistent behavior across different vendors' firmware.
• Downside: it only works if iPXE actually has a native driver for that specific NIC/chipset. iPXE's driver list lags behind newer silicon — recent Intel (e.g. E810/ICE), Broadcom NetXtreme-E, and some Mellanox/NVIDIA ConnectX generations are historically spotty or unsupported.

snponly-x86_64.efi

• Contains no native NIC drivers at all. It exclusively uses UEFI's Simple Network Protocol (SNP) — i.e., it calls into whatever NIC driver the board's UEFI firmware already loaded (vendor-provided).
• Benefit: much broader hardware compatibility. Since virtually every UEFI implementation that can PXE boot already exposes SNP, this "just works" on newer or exotic NICs that iPXE hasn't gotten native driver support for yet. It's also a smaller binary.
• Risk: you're now dependent on the quality of the vendor's SNP implementation. Some vendor UEFI network stacks are known to be slow, have timeouts on larger downloads (e.g. big kernel/initrd images or HTTP(S) boot payloads), or have subtle bugs/memory leaks over long-running operations. You also lose some iPXE-native conveniences — things like reliable link-state handling, MTU/VLAN quirks, and driver-level retry logic are now firmware's problem, not iPXE's.
• Performance can be marginally worse too, since every packet op goes through an extra firmware call layer rather than iPXE talking to the NIC registers directly — though in practice this rarely matters for PXE/boot-time workloads.

Practical guidance for a bare-metal fleet:

• Stick with ipxe-x86_64.efi as the default as you're doing, since it's more predictable and you control the whole stack.
• Reach for snponly-x86_64.efi specifically when you hit a server/NIC combo where the standard build fails to detect the NIC, hangs during link-up, or errors out with something like "no configured network devices" — this is the classic symptom of missing native driver support in iPXE.
• If you go snponly on some hardware, it's worth testing actual HTTP(S) boot of your largest image (initrd/kernel) on that hardware specifically, since that's where flaky vendor SNP implementations tend to show up (timeouts, stalls) rather than in simple DHCP/link-up.
• Some shops build fleet policy as "try native, fall back to snponly per-machine-type" keyed off board/NIC identification, rather than a single global choice — worth considering if you have heterogeneous hardware SKUs in metal-stack.

I am a bit afraid that with this approach some machines will not work. How can we prevent that ?