fix(vm): secureboot vm no default storageclass

[danilrwx]

Description

A SecureBoot virtual machine stores its firmware state in a persistent volume, which needs a StorageClass. KubeVirt only looked at the cluster-wide default StorageClass, so on clusters that rely on the module's own default storage class for virtual disks the volume could not be created and the VM never started — with no reason shown on the VirtualMachine.

Now that module default storage class is also used for the firmware state, and if no storage class can be resolved anywhere, the VirtualMachine reports a clear reason instead of staying pending silently.

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

Enabling SecureBoot without a cluster-wide default StorageClass was a dead end: the VM never started and nothing on the VirtualMachine explained why. Now it works when the module has a default disk storage class, and explains itself when a storage class truly cannot be found.

What is the expected result?

• Module default storage class for virtual disks is set, no cluster-wide default → a SecureBoot VM starts.
• No default storage class anywhere → the VM's Running condition turns False with a message ending in no default storage class found, and starts automatically once one appears.
• Non-SecureBoot VMs are unaffected.

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: vm
type: fix
summary: "SecureBoot virtual machines start using the module default storage class, and report a clear reason when no storage class is available instead of staying pending."