Use virtio-net and virtio-gpu on arm64 again

The base image now carries the VirtIO drivers, which restores the 2304x1440
display that ramfb had lost.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

README.md

@@ -167,7 +167,7 @@ from the shared Windows 11 QCOW2 base image:
 It creates a persistent 64G disk at `vm/windows11/disk.qcow2` as a QCOW2
 overlay on the base image and nothing else: the launcher only creates the
 differential disk and starts QEMU. The base image is generic and holds nothing
-but Windows (see `vm-images/README.md`): no account, no SSH, no VirtIO or other
+but Windows (see `vm-images/README.md`): no account, no SSH, no other
 hardware-specific drivers, no machine identity. Like a cloud image, each VM is
 configured on its first boot, from the seed ISO.
 
@@ -186,9 +186,9 @@ turns off Windows Update and copies the numbered installer scripts
 (`seediso/windows11/NN-*.bat` and `.ps1`) to the desktop folder `Tools`. Later
 starts do not mount the seed ISO.
 
-Because the image has no VirtIO drivers, the VM only uses devices that Windows
-has inbox drivers for: an IDE disk and e1000e NIC on amd64, an NVMe disk, e1000e
-NIC and ramfb display on arm64 (a fixed-size framebuffer there). The SPICE
+The base image carries the VirtIO drivers (`build-windows-base.sh` installs them
+from the virtio-win ISO before generalizing), so on arm64 the VM uses virtio-net and
+virtio-gpu (2304x1440 on macOS); amd64 uses an IDE disk and an e1000e NIC. The SPICE
 vdagent and QEMU Guest Agent come with the VirtIO guest tools, so host/guest
 clipboard integration and the guest agent are not available unless you install
 those tools in the VM yourself.