feat(kubevirt): expose vmStateStorageClass on the KubeVirt CR - #3989

What this PR does

Adds vmStateStorageClass to the kubevirt chart and forwards it from the
platform's iaas bundle, so spec.configuration.vmStateStorageClass on the
KubeVirt CR becomes settable. This is the first direction #3005 lists for the
live-migration regression it reports, and today that field is unreachable from
any values file.

The problem, as #3005 states it

With persistent firmware state restored by #3154 (after #3006 had stripped it),
KubeVirt creates a persistent-state-for-<vm> PVC for every VM whose preference
sets preferredTPM.persistent / preferredEfi.persistent — which is every
windows.11, windows.2k22 and windows.2k25 preference shipped in
kubevirt-instancetypes. backend-storage.getAccessMode reads the CDI
StorageProfile of the cluster-default StorageClass, and the linstor classes
advertise ReadWriteMany for volumeMode: Block only, so the backend PVC is
created ReadWriteOnce. An RWO backend PVC pins the VM to its node: those VMs
can neither be live-migrated nor drained, while the CR asks for
evictionStrategy: LiveMigrate and workloadUpdateMethods: [LiveMigrate, Evict], so node drains and cluster upgrades can wedge on them.

Reproduced on a v1.6.1 cluster (KubeVirt v1.8.4, three nodes):

$ kubectl -n tenant-… get pvc persistent-state-for-vm-instance-<vm>
…  Bound  10Mi  RWO  local

$ kubectl -n tenant-… get vmi vm-instance-<vm> -o yaml   # .status.conditions
LiveMigratable=False  NoTSCFrequencyNotLiveMigratable
RestartRequired=True  memory updated in template spec. Memory-hotplug is only available for migratable VMs

The second condition is the user-visible cost beyond drains: because the VM is
not migratable, vmRolloutStrategy: LiveUpdate cannot hotplug CPU or memory
either. Resizing a Windows VM's instancetype is accepted, staged in the template,
and silently never applied until the VM is stopped and started.

What this changes

• packages/system/kubevirt: vmStateStorageClass value, rendered as
  spec.configuration.vmStateStorageClass only when non-empty. Default ""
  keeps the field omitted, so behaviour is unchanged on upgrade.
• packages/core/platform: same value forwarded onto $kubevirtValues in the
  iaas bundle when non-empty, mirroring resources.cpuAllocationRatio. Without
  this the chart value has no path: the cluster values Secret carries only the
  _cluster block.
• make update: a sixth sed patch with its own grep guard and its own
  sanity-check line. The insert keys off the same evictionStrategy: anchor as
  permittedHostDevices and mediatedDevicesConfiguration, and a guard shared
  with either of them would skip this insert whenever that neighbour is still
  present — the exact trap tests/update_idempotency_test.sh exists to pin, so
  that suite gains the matching case.

What it deliberately does not do

It does not provision an RWX-Filesystem class, and it does not change the
default. Defaulting to replicated would not help: its ReadWriteMany is
Block-only, and the Block-mode backend volume is still a draft
(kubevirt/kubevirt#18215). So this PR delivers the lever #3005 asks for and
leaves the operator to point it at a class that advertises ReadWriteMany for
volumeMode: Filesystem — the NFS-export path the issue mentions, or any other.
Whether cozystack should ship such a class by default, and default this value to
it, looks like a separate decision and a separate PR.

Testing

• make -C packages/system/kubevirt test — helm unittest 7/7, and
  tests/update_idempotency_test.sh PASS including the new case.
• helm unittest packages/core/platform — 33 suites, 140 tests, all pass.
• helm template on the chart: field absent by default, vmStateStorageClass: "nfs-csi" rendered above evictionStrategy when set.

Screenshots

N/A — no UI change.

Downstream repositories

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:

Downstream: not ticked, one open question for a human. Walked the trigger
map file by file against the diff:

• cozystack/website — the diff touches packages/core/platform/values.yaml,
  which the map maps to the hand-written table in
  content/en/docs/next/operations/configuration/platform-package.md. That
  table has no section for the platform's top-level virtualization keys today —
  gpu.* is absent from it as well — so the follow-up is a new section rather
  than a row, and which shape the docs owners want is not my call. Happy to open
  either the docs PR or an issue there, whichever you prefer; say which and it
  is done before this leaves draft.
• terraform-provider-cozystack — no app values.schema.json, kind/plural,
  version enum, release prefix or CRD field is touched. No trigger.
• ansible-cozystack — the role sets networking.* and publishing.* keys
  only; this adds a key it does not pass, and touches no installer values,
  namespace, variant or waited-on object. No trigger.
• ccp, talm, external-apps-example, cozyhr, cozy-proxy, examples,
  cozystack-telemetry-server — nothing under hack/, no package layout,
  namespace, CRD, node prerequisite or release-prep change. No trigger.

Release note

feat(kubevirt): the KubeVirt CR's `vmStateStorageClass` is now settable, as `spec.components.platform.values.vmStateStorageClass` on the platform package and as `vmStateStorageClass` on the kubevirt component. Point it at a StorageClass that advertises `ReadWriteMany` for `volumeMode: Filesystem` to keep the persistent EFI/TPM backend PVC out of ReadWriteOnce, which otherwise makes every Windows VM (persistent TPM/EFI) non-migratable and undrainable, and blocks CPU/memory hotplug on it. Empty by default: no change on upgrade.