feat(drivers): added a virtio-gpu driver so aarch64 QEMU runs the desktop at 1920x1080

[FlareCoding]

Summary

• On aarch64 QEMU the only display with a plain framebuffer is ramfb, which the firmware offers at no more than 1024x768, so the desktop booted at 800x600 while x86_64 ran at 1920x1080.
• A virtio-gpu driver backs the GPU's one resource with RAM and registers it with /dev/gfxfb, stlxdm flushes what it presents when the display asks for it, and make run ARCH=aarch64 uses a 1920x1080 virtio GPU.
• The virtio transport verifies MSI-X vector assignments and makes reset safe before mapping, which also fixes a boot panic on legacy-only virtio-net devices.

---

Note

Medium Risk
New kernel graphics driver and QEMU display switch affect boot/display on aarch64; virtio MSI-X routing changes can fail attach on devices that reject vectors but avoid prior unsafe reset/panic paths.

Overview
Adds a virtio-GPU path for AArch64 QEMU so the desktop can run at 1920×1080 instead of being stuck on firmware-limited ramfb (~1024×768). make run / debug QEMU targets swap -device ramfb for virtio-gpu-pci via QEMU_AARCH64_DISPLAY.

A new virtio_gpu PCI driver implements 2D scanout over the virtio GPU control queue: query display mode, create a B8G8R8X8 backing, register with gfxfb, and flush() dirty rects with batched TRANSFER_TO_HOST_2D + RESOURCE_FLUSH (MSI-X completions when available, otherwise polling with timeout).

stlxdm reads GFXFB_INFO_NEEDS_FLUSH from /dev/gfxfb and issues GFXFB_FLUSH after copying damage when the display requires it, with full-screen retry after a failed flush.

Virtio transport hardening (shared with net/GPU): MSI-X routing functions return errors when the device rejects a vector; virtio-net fails attach on bad routing; reset_device() is a no-op until common config is mapped; virtqueue exposes free_count() for batching; modern GPU device ID uses VIRTIO_DEV_MODERN_BASE.

^{Reviewed by Cursor Bugbot for commit 786d7a4. Bugbot is set up for automated code reviews on this repo. Configure here.}