[WIP] tests/update_eve_image: kvm↔k cross-HV conversion + resize test suite

[eriknordmark]

End-to-end eden tests for the EVE-kvm ↔ EVE-k cross-flavor BaseOs upgrade
and the in-field boot-disk repartition (small → large GPT geometry). They
verify that OCI blobs are reused across the flavor switch (no re-download),
that a deployed app and its volume survive the conversion and a
controller-initiated reboot, that resize variants actually grow the
partitions, and that the TPM-sealed vault stays locally unlocked across the
geometry change.

All scenarios live under tests/update_eve_image/testdata/, each a
self-contained escript with helper scripts and READMEs:

• update_eve_image_cross_hv.txt — base cross-HV upgrade; IMGB reaches
  active on the alternate flavor.
• update_eve_image_cross_hv_with_contenttree.txt — pre-stages a
  ContentTree, asserts zero bytes re-downloaded after the switch.
• update_eve_image_cross_hv_with_app_recreate.txt — app + volume survive
  the switch and a reboot with no re-download.
• update_eve_image_kvm_to_k{,_grow,_resize,_refused,_volmig}.txt —
  repartition variants asserting SMALL→LARGE partition growth,
  BaseOsStatus.Converting device state, blob reuse, local vault unlock
  (VaultStatus.UnlockMethod), and (volmig) live app-volume migration to a
  Longhorn PVC. The volmig leg covers both a VM app's disk volume and a
  container app's data volume; verify reads the container marker from the
  migrated block device, because EVE-k (kubevirt) does not auto-mount a
  container's data volume at its MountDir — tracked as HV=k: container app data volumes not mounted at MountDir when the app has no cloud-init user-data eve#6145.
• update_eve_image_kvm_to_k_geom.txt — geometry-only matrix, parameterized
  by starting release, asserting the boot disk ends at the full EVE-k target
  2+2+10+10 (ESP-A 2G, reserved ESP-B 2G at GPT Make it possible to use pre-built EVE artifacts (instead of building local ones) #7, IMGA/IMGB 10G).
• update_eve_image_kvm_to_k_persist_wipe_restore.txt — persist-wipe restore:
  offline identity + WiFi-cred decrypt after a /persist loss.
• update_eve_image_kvm_to_k_backup_corrupt_restore.txt — backup-corruption
  restore: per-type validity gate + .bak fallback.

Disk-topology setup for the repartition / two-disk / ZFS cases is
prep-kvm-to-k-topology.sh (ext4-shrink, ext4-grow, twodisk-zfs,
twodisk-ext4, ext4-toofull, zfs-grow/zfs-notail).

The whole matrix can be driven in one command with run-kvm-to-k-tests.sh: it
reclaims the single-tenant eden slot before each leg, brings the topology up via
prep-kvm-to-k-topology.sh, runs the matching escript, and prints a PASS/FAIL
summary. RESIZE_EVE_VER=<tag> selects the image under test (required),
BRINGUP_EVE_VER the small-layout start release (default 12.1.0), and
ONLY=/SKIP= narrow to a subset — e.g. ONLY=twodisk-zfs,zfs-grow.

Supersedes #1196 and #1203, folding both into one branch. References
lf-edge/eve#6145.

[eriknordmark]

kvm↔k conversion + resize matrix — full run 7/7 PASS

Ran the complete tests/update_eve_image/testdata/run-kvm-to-k-tests.sh matrix end-to-end on host eden (eden + swtpm, eve.tpm=true).

• Branch: kvm-to-k-eden-tests @ 9eb853a — the test-suite fix this run validates is folded into 9a3fab4 ("tests/update_eve_image: kvm->k conversion test")
• EVE image: lfedge/eve:0.0.0-resize-allprs-6e714932-{kvm,k} (local build), small-start bringup release 12.1.0
• Date: 2026-07-24

===================== SUMMARY =====================
  image: lfedge/eve:0.0.0-resize-allprs-6e714932-{kvm,k}   bringup: 12.1.0
  ext4-shrink    PASS
  ext4-grow      PASS
  twodisk-ext4   PASS
  twodisk-zfs    PASS
  zfs-grow       PASS
  ext4-toofull   PASS
  zfs-notail     PASS
  ----
  PASS=7  FAIL=0  SKIP=0

Fix validated by this run

An earlier run of the same matrix had ext4-shrink FAIL and twodisk-zfs FAIL(prep) from a cross-leg state leak: the single-disk-ZFS legs write eve_install_zfs_with_raid_level into grub.cfg, which eden only rewrites when the certs dir lacks root-certificate.pem. The token therefore persisted into later non-ZFS legs (and across whole runs, since zfs-notail runs last), so those legs booted /persist as ZFS — mis-topologying the ext4 legs (shrink failed "persist is ZFS"; grow false-passed on the wrong fs) and colliding twodisk-zfs's zpool create … persist /dev/sdb against the accidental boot-disk pool.

9a3fab4 fixes it: every non-ZFS-boot leg wipes certs + adam/redis volumes before setup so a token-free grub.cfg is regenerated (P3 defaults to ext4), then asserts /run/eve.persist_type (after SSH is up) so a mis-topology fails loudly instead of false-passing. This 7/7 run is against that fix.