test(conformance): correct stale ImageVolume-gate rationale for k3s v1.36.4

The three KubeVirt VM conformance tests (vm-lifecycle, vm-default-deny,
vm-data-survival) carried comments asserting the ALPHA `ImageVolume` feature
gate is DISABLED "on this k3s v1.31 cluster" and that the apiserver therefore
prunes the container-disk `image` volume, breaking the containerDisk boot path.

The cluster was upgraded v1.31 -> v1.36.4. Revalidated the gate live:
  - kubernetes_feature_enabled{name="ImageVolume"} = 1 (enabled by default;
    stage="" — no longer ALPHA)
  - a server-side `kubectl apply --dry-run=server` of a Pod with an `image`
    volume RETAINS the volume + mount instead of pruning them.

So the old premise is stale: containerDisk roots would boot on 1.36.4. The
tests never asserted the gate state and never used containerDisk — they boot
from CDI DataVolume roots, which remains the correct choice because it is the
spec-required, rebuild-surviving disk model (docs/06, R-STATE-01); an ephemeral
containerDisk could never satisfy data-survival. Test logic is therefore
unchanged; only the explanatory comments are corrected (v1.31 -> v1.36.4, and
the "containerDisk is broken here" rationale marked stale with the live
evidence).

Merge gate: PASS (lint, l0, render-golden, l1 green).

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

conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml

@@ -13,11 +13,16 @@
 #       podSelector:{} NetworkPolicy covers it). R-NET-01 for IaaS.
 #
 # METHOD (virtctl-free): the VM's ROOT is a CDI DataVolume on Longhorn (a mounted
-# PVC — NOT an ephemeral containerDisk, whose boot path is broken on this k3s cluster:
-# KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume gated by the
-# ALPHA `ImageVolume` feature gate, disabled on k3s v1.31, so the apiserver prunes it
-# and the guest dies at OCI init. DataVolume roots bypass that path and are the
-# spec-required disk model — docs/06). cloud-init runs the two probes and writes a
+# PVC — NOT an ephemeral containerDisk), the spec-required, rebuild-surviving disk model
+# for VMs (docs/06, R-STATE-01), matching fixtures/vm.yaml. (Feature-gate note,
+# revalidated 2026-08: an earlier revision said the containerDisk boot path was broken on
+# this cluster — KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume
+# gated by the ALPHA `ImageVolume` feature gate, which k3s v1.31 had DISABLED, so the
+# apiserver pruned it and the guest died at OCI init. That premise is now STALE: the
+# cluster is k3s v1.36.4, where ImageVolume is ENABLED by default
+# (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run RETAINS an
+# `image` volume rather than pruning it), so containerDisk roots would boot — DataVolume
+# is kept because it is the rebuild-surviving model.) cloud-init runs the two probes and writes a
 # PASS/FAIL verdict to a raw Longhorn block disk, then powers off (RerunOnFailure =>
 # stays down). A busybox reader pod reads the verdict back. The container default-deny
 # test proves the datapath fail-closed (default-deny-failclosed, L3); this asserts