vm-disk: source.image does not refuse a golden image that does not exist #4548

A vm-disk with source.image renders and applies even when the golden image it names does not exist in cozy-public. That happens with a typo in the name, and also on any cluster where cozystack.vm-default-images is not enabled, which is the default: packages/core/platform/templates/bundles/iaas.yaml includes it through cozystack.platform.package.optional.default, which is opt-in.

The template turns the image name into a clone source and never looks it up. From packages/apps/vm-disk/templates/dv.yaml on main (6d759cc):

{{- $desiredSource = dict "pvc" (dict "name" (printf "vm-default-images-%s" (required "A valid .Values.source.image.name entry required!" .Values.source.image.name)) "namespace" "cozy-public") }}

A render with a missing name succeeds. helm template d . --set source.image.name=nosuch --set storage=5Gi renders a DataVolume cloning cozy-public/vm-default-images-nosuch, exit 0. On a cluster CDI then waits for that PVC. In CDI v1.66.1 (the version the kubevirt-cdi-operator package ships), validateCloneAndSourcePVC in pkg/controller/datavolume/pvc-clone-controller.go handles a missing source by keeping the current phase and recording a CloneWithoutSource warning, "The source pvc vm-default-images-nosuch doesn't exist", on the DataVolume conditions and events. It requeues when a matching PVC appears, so the disk waits forever on a cluster where the catalog is off.

The reason is visible only on the DataVolume. The VMDisk application is Ready because Ready follows the Helm release. #4380 would make the application show WorkloadsReady=False while the clone waits, but that still leaves the user without the reason at the moment they create the disk.

kubernetes-nodes already refuses the same case. packages/apps/kubernetes-nodes/templates/nodegroup.yaml:325-328 looks up the golden DataVolume in cozy-public and fails the render when it is absent and the pool has no disk yet, with a message that says to enable the catalog.

I'd do the same in vm-disk: on first creation only (no $existingDV), look up the golden and fail with a message that names the image and says the vm-default-images catalog has to be enabled. The open design question is template mode. lookup returns nothing under helm template, helm lint and a dashboard preview, so an absence check fails there too. kubernetes-nodes accepts that and mocks the golden in its unit tests. vm-disk probably should not, and a lookup of the cozy-public Namespace would tell "no cluster to read" from "golden absent". That question is why this is not part of #4392, which adds a guard for a golden whose import has failed.