fix(vm): respect node placement when picking TSC frequency

[eofff]

Description

Bumps 3p-kubevirt to v1.6.2-v12n.60. The only change here is the fork tag in build/components/versions.yml; the actual fix lives in the fork.

The fork now picks the invariant TSC frequency for a VMI only among the nodes that VMI can actually be scheduled on (the pod's nodeSelectors + required node affinity), instead of the cluster-wide minimum.

Fork PR: deckhouse/3p-kubevirt#150

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

VMs that require a pinned TSC frequency — Windows guests (Hyper-V Reenlightenment, enabled automatically for osType: Windows) or invtsc: require — could hang in Pending forever.

The frequency was chosen as the minimum across all schedulable nodes. If that minimum belonged to a node the VM cannot land on (excluded by VMClass CPU-feature selectors, nodeSelector or affinity), and the candidate nodes are non-scalable with that frequency outside the ±250 ppm tolerance, the pod's tsc-frequency-<F> selector never intersects with the rest of its selectors. The pod stays Pending, and since hints are written to the VMI once, it never recovers on its own. Breaks on heterogeneous clusters with per-VM placement constraints.

What is the expected result?

A Windows VM on a VMClass restricted to a subset of nodes gets a TSC frequency native to one of its candidate nodes and schedules normally. Reproduction steps and the behavior matrix are in the fork PR.

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: VMs requiring a pinned TSC frequency (Windows/Hyper-V, invtsc) no longer hang in Pending on heterogeneous clusters — the frequency is now picked among the nodes the VM can actually be scheduled on.