Phase 8 A: virtio-rng entropy source for real Ed25519 signing

The kernel's ed25519_verify() is deliberately verify-only -- no signing,
no keygen, no entropy source. That conflicts with the on-device MINT
word vision (Zuse signing new user certs live at runtime), so this
reopens that constraint on request rather than reshaping MINT around
verify-only.

vm_uuid.h already found the real gap: amd64 has RDRAND, riscv64 has Zkr,
but QEMU's aarch64 CPU models have neither -- confirmed against QEMU
10.2.1. A deterministic PRNG (fine for VM UUIDs) is not safe for key
generation, so this adds a virtio-rng device instead of a per-arch split:
real host entropy, identical guest-side protocol on all three arches.

New src/starkernel/virtio/virtio_rng.c + include/starkernel/virtio_rng.h,
transport plumbing mirroring the existing virtio_blk.c driver exactly.
Wired into kernel_main.c boot, -device virtio-rng-pci added to all three
QEMU targets.

Verified live (temp probe, written/run/captured/reverted): 16 real bytes
pulled through the full request/notify/poll round trip on all three
arches, three different values confirming real entropy. Final boot
against the reverted, permanent code: clean compile, clean boot to ok>
on amd64/aarch64/riscv64, Stadium conservation intact, no panics or
guest errors.

Ed25519 keygen/signing itself (Phase B) and the MINT word design
(Phase C) remain open, documented in FABRIC-3.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd

src/starkernel/kernel_main.c

@@ -64,6 +64,7 @@ EFI_RUNTIME_SERVICES *g_sk_runtime_services = NULL;
 #include "starkernel/repl.h"
 #include "starkernel/pci.h"
 #include "starkernel/virtio_blk.h"
+#include "starkernel/virtio_rng.h"
 #include "starkernel/virtio_input.h"
 #include "starkernel/xhci_driver.h"
 #include "block_subsystem.h"
@@ -610,6 +611,23 @@ static void kernel_main_deep(BootInfo *boot_info) {
         }
     }
 
+    /* Phase 8: virtio-rng entropy source. Real per-arch RNG doesn't cover
+     * all three architectures (amd64 RDRAND, riscv64 Zkr, but aarch64 has
+     * neither in QEMU's CPU models -- see vm_uuid.h's identical finding),
+     * so signing/keygen entropy comes from this paravirtualized device
+     * instead. Unconditional call site, same graceful-noop precedent as
+     * virtio_blk_find_artemis() above -- boot proceeds either way, the
+     * device is only required once something actually calls
+     * virtio_rng_get_bytes(). */
+    {
+        int rrc = virtio_rng_init();
+        if (rrc == 0) {
+            console_println("virtio-rng: ready");
+        } else {
+            console_println("virtio-rng: not available (continuing without)");
+        }
+    }
+
     /* item 4.3.5c: virtio-keyboard-pci, riscv64 only today. Unconditional
      * call site, same as virtio_blk_find_artemis() above -- the function
      * itself no-ops with a console message on architectures/boards where