vm-default-images installs without health checks, so a failed golden-image import reports green and surfaces on the disks that clone it #4169

packages/system/vm-default-images renders one DataVolume per image in templates/dv.yaml, each carrying cdi.kubevirt.io/storage.bind.immediate.requested: "true", so the import starts at install rather than waiting for a consumer. The PackageSource that installs it, packages/core/platform/sources/vm-default-images.yaml, sets no healthCheckExprs on the component's install: block.

Nothing then waits for those imports. Our own field documentation describes the outcome for exactly this shape: the HelmRelease "reports Ready as soon as helm applies the CR, with no error or warning". So an image that fails to download, or one whose import stalls, leaves the release green.

The part that makes it worth fixing rather than noting is what sits downstream. source.image on a vm-disk clones from these volumes, and the clone has no way to tell a completed import from one that never finished. The failure surfaces later, on a disk the user created, in a place that has nothing to do with the image collection.

HealthCheckExprs is already on ComponentInstall (api/v1alpha1/packagesource_types.go:164), so the fix goes in the same install: block that already carries namespace and releaseName. The expressions would be the DataVolume ones, the same shape being added for vm-disk-rd.

Two things worth deciding together with it. A stalled import would now hold the install window rather than returning immediately, and the images are large, so the window needs a number chosen for a download rather than the platform default. And an image that genuinely cannot be fetched would keep the whole component from going Ready, which is the right answer only if a missing image should block the collection rather than degrade it.

Found while adding the same gate one layer down, on the vm-disk ApplicationDefinition. This is the one remaining place in the tree that renders a DataVolume without one.