VEP #25: Infer backup target StorageClass from source VM volumes

Is your feature request related to a problem? Please describe: Related to VEP 25: Incremental backup with CBT and #17852.

VirtualMachineBackup currently requires spec.pvcName, and the backup controller expects that target filesystem PVC to have already been provisioned. Issue #17852 proposes provisioning and managing this scratch/target PVC inside KubeVirt. When that provisioning is implemented, clusters without a default StorageClass still need a deterministic way to select a StorageClass.

Many VMs already have one or more PVC- or DataVolume-backed disks attached with an explicit storageClassName. KubeVirt could use those existing claims as a source for selecting the StorageClass of an automatically provisioned backup target PVC. Without this fallback, automatic provisioning would fail on clusters that intentionally have no default StorageClass, even though the VM's storage already identifies a usable class.

Describe the solution you'd like: When KubeVirt automatically provisions a target PVC for VirtualMachineBackup, select its StorageClass using an explicit and deterministic precedence:

1. Honor an explicitly supplied target PVC, volume claim template, or StorageClass policy.
2. Otherwise inspect the source VM/VMI's persistent volumes, resolving both PVC- and DataVolume-backed volumes to their bound PVCs.
3. Collect non-empty spec.storageClassName values from those PVCs.
4. If exactly one unique StorageClass is found, use it for the generated backup target PVC.
5. If multiple unique StorageClasses are found, do not select one based on volume order; report an actionable condition requiring an explicit StorageClass or target PVC.
6. If none is found, fall back to the cluster's default StorageClass when one exists; otherwise report an actionable condition explaining that no StorageClass could be selected.

The generated target must remain a filesystem-mode PVC, as required by the current backup path.

Add unit and functional coverage for:

• A VM with one PVC-backed disk and no default StorageClass.
• A VM with a DataVolume-backed disk and no default StorageClass.
• Multiple disks using the same StorageClass.
• Multiple disks using different StorageClasses.
• No persistent source volumes and no default StorageClass.
• An explicit target PVC or StorageClass overriding inference.

Describe alternatives you've considered:

• Require every integration to pre-create the target PVC. This is the current behavior and duplicates storage-selection and lifecycle logic outside KubeVirt.
• Require an explicit StorageClass or volume claim template for every backup. This is deterministic but unnecessarily verbose when all persistent VM disks already use the same class.
• Always use the cluster default StorageClass. This does not work on clusters that intentionally have no default.
• Select the first persistent VM volume. This is ambiguous for multi-disk VMs and makes behavior depend on volume ordering.

Additional context: The relevant API is defined in staging/src/kubevirt.io/api/backup/v1alpha1/types.go. At present, CEL validation requires spec.pvcName, and the controller verifies and hot-plugs that existing PVC rather than provisioning one.

This request is specifically about StorageClass selection for the internal PVC-provisioning lifecycle proposed by #17852, not about changing the StorageClass of an existing user-provided target PVC.

/sig storage /kind enhancement