feat(storage): CSI snapshots + smart-clone + migratable RWX for KubeVirt live-migration

Adds the VM/CDI storage tier approved by the PM (RWX for live-migration):

- platform/external-snapshotter (NEW, controllers pass): the cluster-singleton
  snapshot.storage.k8s.io control plane (CRDs + snapshot-controller in
  kube-system), pinned v8.2.0 (Kubernetes deps aligned to 1.31 since v8.1.0;
  this cluster is k3s v1.31.5). These CRDs were absent — only snapshots.longhorn.io
  and kubevirt.io snapshot CRDs existed.
- platform/longhorn/volumesnapshotclass.yaml (NEW, platform-config): the
  driver.longhorn.io VolumeSnapshotClass (type: snap, in-cluster).
- platform/kubevirt/cdi-storageprofiles.yaml (NEW, platform-config): StorageProfile
  longhorn -> cloneStrategy: snapshot; StorageProfile longhorn-vm -> snapshot clone
  + claimPropertySets RWX/Block. Non-degraded default virt class clears
  CDIDefaultStorageClassDegraded.
- platform/longhorn/storageclasses.yaml: NEW longhorn-vm StorageClass —
  migratable: "true" (Longhorn's KubeVirt-live-migration knob; RWX/Block-only on
  1.7.3), is-default-virt-class (NOT the k8s default; longhorn stays RWO default).
- platform/kubevirt/kubevirt-cr.yaml: comment only — LiveMigration is GA on v1.9
  (no feature gate); no cluster-wide evictionStrategy (would wedge RWO-disk drains);
  live-migration stays per-VM opt-in on a longhorn-vm disk.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

platform/longhorn/storageclasses.yaml

@@ -29,6 +29,52 @@ parameters:
   dataLocality: "disabled"       # keep replicas spread for durability, not co-located with the pod
   fsType: "ext4"
 ---
+# KubeVirt VM-disk tier — RWX + migratable, for LIVE-MIGRATABLE VM disks (ADR-0005, docs/06).
+#
+# WHY a second Longhorn class: the default `longhorn` class is ReadWriteOnce (a Longhorn volume
+# attaches to ONE node). KubeVirt live migration needs the SOURCE and TARGET virt-launcher pods to
+# hold the SAME disk on TWO nodes for the migration window, which requires ReadWriteMany. Longhorn
+# provides this via the StorageClass parameter `migratable: "true"`.
+#
+# migratable RWX on Longhorn 1.7.3 is BLOCK-mode only (verified against Longhorn 1.7 docs + the live
+# cluster: longhornio/longhorn-manager:v1.7.3). Longhorn's ORDINARY RWX (migratable=false) is an
+# NFS/share-manager-backed *Filesystem* export; the MIGRATABLE RWX path is different — it is a raw
+# block device that Longhorn allows attached to two nodes ONLY during a live migration (concurrent
+# writers are not permitted, so a mounted filesystem could be corrupted). Therefore:
+#   * StorageClass parameter        migratable: "true"
+#   * PVC/DataVolume accessModes     ReadWriteMany
+#   * PVC/DataVolume volumeMode      Block            (Filesystem is NOT supported with migratable)
+# The volumeMode/accessMode live on the PVC/DataVolume; CDI stamps them automatically for disks on
+# this class via the matching StorageProfile claimPropertySets (../kubevirt/cdi-storageprofiles.yaml).
+#
+# is-default-virt-class: CDI treats THIS as the default *virtualization* StorageClass (precedence over
+# the k8s default `longhorn` for VM disks when storageClassName is omitted). Because it supports smart
+# clone (snapshot) AND ReadWriteMany, its StorageProfile is non-degraded — which is what clears the
+# CDIDefaultStorageClassDegraded alert. It is NOT the cluster (k8s) default: `longhorn` keeps the
+# storageclass.kubernetes.io/is-default-class annotation, so ordinary PVCs still land on RWO longhorn.
+# Exactly one SC may carry is-default-virt-class (else CDIMultipleDefaultVirtStorageClasses fires).
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: longhorn-vm
+  annotations:
+    storageclass.kubevirt.io/is-default-virt-class: "true"
+provisioner: driver.longhorn.io
+allowVolumeExpansion: true
+reclaimPolicy: Delete            # dev: reclaim space when the PVC is deleted
+volumeBindingMode: Immediate
+parameters:
+  # Same 3-replica durability as the default class (HARD node anti-affinity in helmrelease.yaml).
+  # Quoted string literals — see the numberOfReplicas note on the `longhorn` class above.
+  numberOfReplicas: "3"
+  staleReplicaTimeout: "30"
+  dataLocality: "disabled"
+  # THE knob that makes this class usable for KubeVirt live migration: mark volumes migratable so a
+  # RWX Longhorn volume can be attached to two nodes during a live migration. (Block-mode only.)
+  migratable: "true"
+  # No fsType: migratable RWX volumes are Block-mode (raw device); a filesystem is never laid down
+  # by Longhorn here — the guest owns the block device.
+---
 # Bulk media tier — large, NON-replicated data (Plex library, download staging, arr handoff).
 # docs/04 / R-STATE-04: 3x replicating multi-TB media across 3 mini-PCs is impractical, so bulk
 # media lives OUTSIDE the cluster and is consumed as an external NFS/SMB mount via this thin

platform/longhorn/volumesnapshotclass.yaml

@@ -0,0 +1,28 @@
+---
+# Longhorn VolumeSnapshotClass — the CSI snapshot recipe for driver.longhorn.io.
+#
+# CONSUMES the snapshot.storage.k8s.io CRD registered by platform/external-snapshotter (controllers
+# pass), so — like the KubeVirt/CDI CRs — this CR is applied by the `platform-config` Flux
+# Kustomization (dependsOn: platform), not in the controllers pass. It lives HERE beside the Longhorn
+# component for locality and is referenced in place from platform-config/kustomization.yaml.
+#
+# WHY: this is what turns "Longhorn has a CSI driver" into "the cluster can take CSI VolumeSnapshots
+# of Longhorn PVCs". CDI's snapshot smart-clone (cdi-storageprofiles.yaml -> cloneStrategy: snapshot)
+# resolves the driver's VolumeSnapshotClass by matching driver name; this is the only one for
+# driver.longhorn.io, so CDI selects it unambiguously (no is-default-class annotation needed).
+#
+# type: snap  -> an in-cluster Longhorn snapshot on the volume's own replicas (fast, no external
+#                backupstore required). The alternative `type: bak` uploads to a backup target, which
+#                is not configured until Phase 4 (Velero/backupTarget). Clone/restore stay in-cluster.
+# deletionPolicy: Delete -> when the VolumeSnapshot is deleted, its Longhorn snapshot is cleaned up.
+#                CDI's clone snapshots are transient, so leaking them would waste replica space.
+apiVersion: snapshot.storage.k8s.io/v1
+kind: VolumeSnapshotClass
+metadata:
+  name: longhorn
+  labels:
+    app.kubernetes.io/part-of: longhorn
+driver: driver.longhorn.io
+deletionPolicy: Delete
+parameters:
+  type: snap