fix(vi): attach PVC-backed images to VMs in read-only mode

[eofff]

Description

VirtualImage with storage: PersistentVolumeClaim / Kubernetes was attached to a VM as a regular writable PVC volume, while registry-backed images (storage: ContainerRegistry) are always read-only (ContainerDisk).

Now a PVC-backed image is attached read-only in both paths:

• Static attach (.spec.blockDeviceRefs): the controller sets readonly: true on the disk target and readOnly: true on the PVC volume source (kvbuilder).
• Hotplug (VMBDA → addvolume subresource): virtualization-api sets the same flags when mutating the hotplug request. ISO images are not affected: CD-ROM is read-only by default.

Why do we need it, and what problem does it solve?

Images are immutable by design, and the documentation states that images are connected in read-only mode. However, a guest OS could write to a PVC-backed image, corrupting it for all VMs using this image.

What is the expected result?

1. Create a VirtualImage with storage: PersistentVolumeClaim.
2. Attach it to a VM via .spec.blockDeviceRefs or VirtualMachineBlockDeviceAttachment.
3. Inside the guest the disk is read-only (lsblk shows RO=1), writes fail with a write-protect error.

Note: for already attached images the change is applied after VM restart (static attach) or VMBDA re-attach (hotplug). VMs with enableParavirtualization: false cannot use read-only non-ISO disks on the SATA bus (KubeVirt restriction).

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vi
type: fix
summary: "PVC-backed virtual images are now attached to virtual machines in read-only mode, like registry-backed images."