vmm: build BoxLite's own VMM and guest kernel #1512

Goal

Build BoxLite's own virtualization stack and run every box on it:

• VMM: a Rust VMM for BoxLite on Hypervisor.framework (macOS arm64) and KVM (Linux x86_64 and arm64), linked as a library into boxlite-shim.
• Guest kernel: a pinned Linux LTS kernel with BoxLite's config, built in CI and shipped as a file.
• Guest init: boxlite-guest runs as PID 1.

When the new stack is the default, remove libkrun and libkrunfw. Then build on it: hot-plug mounts, dynamic resource adjustment, memory snapshots, GPU support, and native Windows hosts.

Not in scope

• Changes to libkrun. It ships unchanged until the new VMM is the default.
• More than one VM per process, confidential computing, live migration, Intel Macs.

Why

• The shim should get the VM's outcome. It needs the guest exit status and typed errors back, instead of the process exiting inside the engine.
• The guest kernel ships as a shared library loaded with dlopen. That keeps breaking on some hosts: fix(jailer): set LD_LIBRARY_PATH in bwrap sandbox so the shim can dlopen libkrunfw #846, fix(musl): run static shim without libkrunfw dlopen #937, chore(musl): revert static shim libkrunfw dlopen change (#937) #1019, fix(libkrun-sys): let a static shim dlopen libkrunfw #1084, fix(libkrun-sys): keep libkrunfw's libc dependency aarch64-only #1145, aarch64 Linux: boxlite-shim (static glibc 2.28) cannot dlopen libkrunfw.so.5 on glibc 2.39 host — "VM failed to start (libkrun status=-2)" #1509.
• Every directory volume gets its own device today. With three of them, boxes fail to start with IrqsExhausted (Multiple directory volume mounts fail with RegisterNetDevice(IrqsExhausted) on Linux/libkrun #935).
• Owning the stack is what makes the new capabilities possible: mounts added to a running box, resizing, memory snapshots for AutoPause (Feature: AutoPause / AutoResume #1003), GPU.

Milestones by priority

Each milestone's description holds its goal, tasks and done-when. Open an issue in the milestone when work on a task starts.

P0 (highest): boxes work exactly as they do today

• VMM M0: Foundations
• VMM M1: First boot
• VMM M2: First box
• VMM M3: Volumes
• VMM M4: Production hardening
• VMM M5: Default on

P1: new capabilities, after P0

The M0 design leaves room for these, so they don't need a redesign later.

• VMM M6: Hot-plug mounts
• VMM M7: Dynamic resources
• VMM M8: Memory snapshot
• VMM M9: GPU support
• VMM M11: Own network backend

P2 (lowest): Windows hosts

Windows boxes already run through WSL2.

• VMM M10: Windows hosts