fix(vmclass): recompute cpu features so vms can schedule on listed available nodes

[fl64]

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

A VirtualMachineClass with cpu.type: Discovery could become impossible to schedule VMs onto after the cluster's node composition changed (new worker nodes joined, an old generation drained, etc.). The user-visible symptom was a VM stuck in Pending with the condition:

Could not schedule the virtual machine: Unschedulable: 0/N nodes are available:
N node(s) didn't match Pod's node affinity/selector.

The class looked healthy (Status.AvailableNodes listed matching nodes, the Discovered condition was True), but the virt-launcher pod's nodeSelector required CPU feature labels — such as hle/rtm from an Intel Haswell generation — that the current worker nodes no longer provided. Those features had been captured from the very first reconcile and were never refreshed.

What is the expected result?

After the fix the controller recomputes common CPU features from the current availableNodes on every reconcile, so:

• VM classes correctly advertise only features present on every node they can run on.
• Adding or removing worker nodes (drain, decommission, scale-out) no longer leaves stale feature requirements behind.
• VMs that used to be stuck in Pending start scheduling as soon as the next reconcile runs.

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.

section: core
type: fix
summary: "VirtualMachineClass with cpu.type=Discovery no longer keeps stale CPU features captured at first reconcile; features are recomputed from the current set of available nodes on every reconcile."