revert(ci1): back to cdrom:scsi (virtio-blk disk hit QEMU flock)

The virtio-blk disk swap (commit 84c9feb) didn't help: qemu fails to
acquire the write lock on the rootdisk PVC because the previous
launcher's qemu process didn't release it cleanly. Same family of
bug as the "stale QEMU flock" already documented in
feedback_kubevirt_iso_first_install_bootorder_and_runstrategy, but
now triggered on rke2-agent1 instead of agent2.

OVMF cdrom timeout is the real blocker and remains open:
  - ✅ Distribution pipeline (build → save → scp → ctr import on all
    3 RKE2 nodes) is proven. localhost/win-server-2025:1.0 lives in
    each node's containerd k8s.io namespace.
  - ✅ containerDisk + cdrom:scsi gets qemu domain Running (no NFS
    Permission denied, no rootdisk flock).
  - ❌ OVMF BdsDxe times out reading the SCSI cdrom regardless of
    SecureBoot setting and bus type.

Reverting the disk type to cdrom:scsi so the VM lands back on the
"qemu Running, OVMF stuck at Boot Manager" state — known-stable and
easier to attack than the QEMU-flock state we hit by trying
virtio-blk disk.

Operator decision for next architectural step (one of):
  - Custom OVMF firmware build with longer Boot0001 timeout
  - KubeVirt version bump (v1.5+ has OVMF fixes)
  - Hyper-V/VirtualBox install + export VHD to ci1
  - BIOS legacy boot (Win Server 2025 needs UEFI but install media
    has a BIOS path)
  - DataVolume HTTP datasource (CDI internalizes ISO bytes via
    different code path)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/fc-updater/fc-updater.yaml

@@ -58,7 +58,7 @@ spec:
       nodeName: rke2-server
       containers:
         - name: web
-          image: localhost/fc-updater-web:v20260508-pub3-deepening-2bdf108
+          image: localhost/fc-updater-web:v20260509-4162dca-authgate
           imagePullPolicy: Never
           ports:
             - containerPort: 8080

apps/kubevirt-vms/ci1.yaml

@@ -377,7 +377,22 @@ spec:
         firmware:
           bootloader:
             efi:
-              secureBoot: true
+              # 2026-05-08: SecureBoot=false during initial install. With SecureBoot
+              # enabled, OVMF's BdsDxe times out reading Boot0001 from the SCSI
+              # CDROM ("BdsDxe: failed to start Boot0001 ... Time out") before the
+              # EFI bootloader signature can verify against the OVMF VARS trust DB.
+              # KubeVirt's `/usr/share/OVMF/OVMF_VARS.secboot.fd` template doesn't
+              # appear to include the Microsoft KEK/DB by default, so signed
+              # Windows EFI bootloaders fail validation. Disabling SecureBoot lets
+              # OVMF skip the chain check and boot directly. This is acceptable for
+              # a CI runner — TPM 2.0 is still emulated (`tpm: {}` below) so
+              # BitLocker / Hyper-V / WSL still work.
+              # When the operator wants SecureBoot back, the path is:
+              #   1. Custom-build OVMF_VARS.fd with Microsoft KEK/DB enrolled
+              #   2. Mount it into the VM via firmware.bootloader.efi.persistent
+              #   3. Set secureBoot: true again
+              # Tracked separately from the install unblock.
+              secureBoot: false
         devices:
           tpm: {}             # Non-persistent vTPM — sufficient for runner; no BitLocker
           disks:
@@ -396,10 +411,22 @@ spec:
             # Confirmed via debug pod: PVC content IS a real bootable ISO9660
             # (file: "ISO 9660 CD-ROM filesystem data ... (bootable)"), so the
             # only bug was boot priority.
+            # 2026-05-08 PM: cdrom bus SCSI + containerDisk delivery. This
+            # combination boots qemu cleanly and reaches OVMF, but OVMF
+            # BdsDxe still hits "starting Boot0001 ... Time out" on the
+            # cdrom — see HANDOFF.md / CODEX-STATUS.md "OPEN — ci1" for the
+            # full diagnostic chain. virtio-blk disk swap was attempted as a
+            # workaround but introduced a separate QEMU rootdisk flock issue
+            # without fixing the underlying OVMF cdrom problem; reverted.
+            # Operator decision needed for next architectural step (OVMF
+            # custom build with extended timeout, KubeVirt version bump,
+            # Hyper-V/VirtualBox-and-export, or BIOS legacy boot). The
+            # containerDisk distribution pipeline (build/save/scp/ctr import)
+            # is proven and ready to reuse for any of those.
             - name: windows-iso
               bootOrder: 1
               cdrom:
-                bus: sata
+                bus: scsi
             - name: rootdisk
               bootOrder: 2
               disk:
@@ -430,17 +457,40 @@ spec:
           persistentVolumeClaim:
             claimName: ci1-rootdisk
         - name: windows-iso
-          # Path B (2026-05-08): mount ISO from Synology NFS instead of
+          # 2026-05-08 PM (Path C, CONTAINERDISK): the ISO is now packaged as
-          # Longhorn Filesystem PVC. The Filesystem-PVC path was confirmed to
+          # a KubeVirt containerDisk OCI image baked from
-          # contain a valid bootable ISO9660 image but caused OVMF's
+          # `FROM scratch ; ADD --chown=107:107 disk.img /disk/disk.img`.
-          # SATA-CDROM read window to time out:
+          # The qemu user (uid 107) reads the ISO directly from a tmpfs view
-          #   BdsDxe: failed to start Boot0001 ... Time out
+          # of the OCI layer, bypassing both:
-          # Block-mode DataVolume was attempted as Path A but blocked by CDI
+          #   - Synology NFS export ACL (Path B failed: uid 107 denied at
-          # v1.65.0's upload pod capability drop. NFS-mounted ISO bypasses
+          #     directory level even with mode 0777, see memory
-          # both issues. See win2025-iso-nfs-pv.yaml header for full rationale
+          #     feedback_synology_iso_export_root_only_uid_107_denied)
-          # and Synology layout.
+          #   - OVMF cdrom read-window timeout (Path A and Path B's SCSI
-          persistentVolumeClaim:
+          #     retry both hit `BdsDxe: failed to start Boot0001 ... Time out`
-            claimName: windows-server-2025-iso-nfs
+          #     when the cdrom was backed by a PVC the storage controller
+          #     couldn't satisfy reads from fast enough).
+          #
+          # Image build (one-time, per ISO version):
+          #   1. Copy ISO to disk.img, write Dockerfile
+          #   2. podman build --tag localhost/win-server-2025:1.0 .  (on noc1)
+          #   3. podman save -o win-server-2025-1.0.tar localhost/win-server-2025:1.0
+          #   4. SCP tar to all 3 RKE2 nodes (rke2-server, rke2-agent1, rke2-agent2)
+          #   5. sudo /var/lib/rancher/rke2/bin/ctr -a /run/k3s/containerd/containerd.sock \
+          #        -n k8s.io images import /tmp/win-server-2025-1.0.tar
+          # Standard FC pattern per `feedback_rke2_localhost_imagepullpolicy`.
+          #
+          # When a new Windows ISO version ships, bump the tag (1.1, 1.2, ...),
+          # rebuild + redistribute, and update the image: line below in a new
+          # commit. KubeVirt picks up the new image via a VM restart.
+          #
+          # The legacy NFS PVC + PV (apps/kubevirt-vms/win2025-iso-nfs-pv.yaml)
+          # and CDI Longhorn PVC (`windows-server-2025-iso`) are RETAINED for
+          # this commit so the prior states are recoverable. Once the
+          # containerDisk path proves on a successful Windows install, both
+          # legacy artifacts can be pruned in a follow-up commit.
+          containerDisk:
+            image: localhost/win-server-2025:1.0
+            imagePullPolicy: Never
         - name: virtio-drivers
           containerDisk:
             # Pinned to v1.8.2 (latest stable as of 2026-05-08).