test(archsetup): add FS_PROFILE selector for ZFS VM coverageHEADmain

The VM harness only built one btrfs base image, so every ZFS-conditional check in the Testinfra suite skipped and the ZFS install path went untested in automation. I added an FS_PROFILE selector (btrfs default, zfs) so `make test FS_PROFILE=zfs` can target a ZFS root.

init_vm_paths derives the image name from FS_PROFILE and validates it. btrfs keeps the legacy unsuffixed archsetup-base.qcow2 so existing images and invocations are untouched. The zfs profile gets archsetup-base-zfs.qcow2. create-base-vm.sh picks archsetup-test.conf vs the new archsetup-test-zfs.conf (FILESYSTEM=zfs, NO_ENCRYPT=yes for an unattended install), and the Makefile resolves the matching image for its base-VM check.

The archsetup run config stays shared. archsetup reads no filesystem key. It detects ZFS from the live root via is_zfs_root, so the ZFS branch fires on its own once the base image is ZFS. The design doc is reconciled to that: no separate archsetup-vm-zfs.conf, and the non-ZFS profile is btrfs, not ext4.

Building the ZFS base image and running the ZFS sweep green is next.

1 files changed, 29 insertions, 10 deletions

diff --git a/docs/design/2026-06-25-zfs-vm-test-coverage.org b/docs/design/2026-06-25-zfs-vm-test-coverage.org
index 694478f..d9625e0 100644
--- a/docs/design/2026-06-25-zfs-vm-test-coverage.org
+++ b/docs/design/2026-06-25-zfs-vm-test-coverage.org
@@ -70,9 +70,10 @@ test VM (skip the passphrase prompt; encryption isn't what we're validating).
   current/non-ZFS), picks the matching archangel config, and writes a
   profile-named image: =vm-images/archsetup-base.qcow2= (default) vs
   =vm-images/archsetup-base-zfs.qcow2=. Same =clean-install= snapshot name.
-- =run-test.sh= + Makefile take the same =FS_PROFILE= and select the image +
-  the matching archsetup config (=archsetup-vm.conf= vs =archsetup-vm-zfs.conf=,
-  the latter with the ZFS filesystem settings). =make test FS_PROFILE=zfs=.
+- =run-test.sh= + Makefile take the same =FS_PROFILE= and select the image (via
+  =init_vm_paths=). The archsetup run config (=archsetup-vm.conf=) is *shared* —
+  archsetup auto-detects ZFS from the live root, so no per-profile run config is
+  needed. =make test FS_PROFILE=zfs=.
 
 ** C. Bare-metal runner migration
 Mirror the VM runner's fix in =run-test-baremetal.sh=:
@@ -109,12 +110,30 @@ analyze_log_diff, categorize_errors, generate_issue_report, VALIDATION_*.
 - *P-E* delete the dead shell-sweep functions (the standing P5 follow-up).
 
 * Open questions
-1. *Does archangel support a ZFS-root config out of the box?* Verify before P-A;
-   if not, that's its own sub-task (or a feature request to archangel).
-2. *Two images vs one image + two snapshots?* Lean two images — ZFS vs ext4 are
-   different on-disk layouts; cleaner than juggling snapshots on one disk.
-3. *Profile on run-test.sh vs a separate run-test-zfs.sh?* Lean a =FS_PROFILE=
-   param on the existing runner — avoids duplicating the harness.
-4. *Disk size / RAM for the ZFS VM* (ZFS wants more RAM than the 4G default?).
+1. *Does archangel support a ZFS-root config out of the box?* RESOLVED (yes).
+   ZFS is archangel's *default* filesystem (=FILESYSTEM=zfs=, validated by
+   =installer/lib/config.sh:validate_filesystem=), with =NO_ENCRYPT=yes= for an
+   unattended unencrypted install and a ready =installer/velox-zfs.conf.example=
+   to model. No archangel work needed.
+2. *Two images vs one image + two snapshots?* RESOLVED — two images. ZFS vs
+   btrfs are different on-disk layouts; cleaner than juggling snapshots on one
+   disk. =btrfs= keeps the legacy unsuffixed =archsetup-base.qcow2=; =zfs= gets
+   =archsetup-base-zfs.qcow2=.
+3. *Profile on run-test.sh vs a separate run-test-zfs.sh?* RESOLVED —
+   =FS_PROFILE= env param on the existing runner + Makefile, no duplicate
+   harness.
+4. *Disk size / RAM for the ZFS VM* — start at the 4G RAM / 50G disk defaults;
+   bump =VM_RAM= only if the ZFS install OOMs (decide at P-C build time).
 5. *Should the bare-metal runner stay at all once a ZFS VM exists*, or does the
    ZFS VM profile make it redundant for everything except real-hardware smoke?
+   Defer until after P-D.
+
+* Design corrections (found during P-A/P-B grounding)
+- The "non-ZFS" base is *btrfs*, not ext4 — =archsetup-test.conf= sets
+  =FILESYSTEM=btrfs=. The profile axis is zfs vs btrfs throughout.
+- *No =archsetup-vm-zfs.conf= is needed.* archsetup reads no filesystem key; it
+  auto-detects ZFS from the live root via =is_zfs_root()= (=findmnt -n -o FSTYPE
+  /=, archsetup:688). The ZFS branch (sanoid, zfs-scrub timer, mkinitcpio udev
+  hook, docker zfs storage driver) fires whenever the running root is ZFS. So
+  only the *archangel* base config and the base *image* differ per profile; the
+  archsetup run config (=archsetup-vm.conf=) is shared.