Container apps on eve-k run as kubevirt shim VMIs (VirtualizationMode != NOHYPER)
launched from eve-external-boot-image. Two HV=k-only gaps relative to HV=kvm
are addressed:

1. Cloud-init env vars never reached the guest. On HV=kvm/xen the snapshot-
   mount path projects env vars into /environment on the rootfs via the OCI
   spec. On HV=k the container rootfs is a read-only PVC at /dev/vda, so that
   path is not available.

2. Customer-attached volumes were visible in the guest but never mounted, so
   the container ran without its persistent data.

Pillar side:
- pkg/pillar/cmd/domainmgr/domainmgr.go: when hvTypeKube &&
  VirtualizationMode != NOHYPER, emit a synthetic DiskStatus with
  Devtype="cloudinit-nocloud" and the env map rendered as sorted shell
  KEY="value" lines (escaping " and \). Refactor the VM-app cloud-init ISO
  path into appendCloudInitDisk so its behavior is unchanged; the new
  branch lives alongside it.
- pkg/pillar/hypervisor/kubevirt.go: translate the cloudinit-nocloud
  DiskStatus into v1.Volume{CloudInitNoCloud: {UserDataBase64: ...}} attached
  as a read-only sata cdrom. Base64 keeps the payload out of plaintext
  `kubectl describe vmi`.

Initrd side (pkg/xen-tools/initrd):
- init-initrd: for root != 9p (i.e. HV=k path, not HV=kvm/xen which already
  projects env vars via OCI), probe for a cdrom with LABEL=cidata, mount it
  iso9660, and source user-data lines as `export KEY=value` into
  /mnt/environment. Parse raw `blkid` output by hand — busybox's
  `blkid -L cidata` returns empty in the eve-external-boot-image build even
  when raw `blkid` enumerates the device with the correct LABEL field. No
  modprobe is needed; iso9660 and the sata/sr_mod stack are built into the
  eve-external-boot-image kernel.
- mount_disk.sh: skip the boot block device. On HV=k the container PVC is
  itself the boot block device, already mounted at /mnt. Without the skip
  it would be treated as the first extra volume — either remounting the
  rootfs on top of itself, or consuming mountPoints line 1 and shifting
  every subsequent device-to-path mapping down by one, leaving the
  customer's actual extra volume (/dev/vdb) either unreached or mapped to
  the wrong target. On HV=kvm/xen root=9p has no block device at /mnt so
  the guard is a no-op there.
- mount_disk.sh: exit cleanly when /mnt/mountPoints is absent (image
  declared no VOLUMEs — writeKubevirtMountpointsFile in
  pkg/pillar/cas/containerd.go gates the write on len(mountpoints) > 0),
  instead of erroring on every enumerated block device.

Build system (Makefile):
- Set `pkg/external-boot-image: FORCE_BUILD := --force`. The package tag
  is hashed only from git-tracked files (Dockerfile.in, build.yml), so it
  never changes when xen-tools changes. Without --force, `linuxkit pkg build`
  short-circuits on cache-hit and keeps serving stale runx-initrd
  indefinitely, regardless of init-initrd / mount_disk.sh edits.
- Set `pkg/kube: FORCE_BUILD := --force` for the same reason one level up:
  pkg/kube bundles pkg/kube/external-boot-image.tar which is gitignored, so
  changes to it don't change pkg/kube's hash. Without --force, the eve-kube
  image in cache keeps the old tar baked in, and the rootfs ships stale
  content to the device.

Signed-off-by: Pramodh Pallapothu <pramodh@zededa.com>