ci: build images with the production LongQT OpenCore + unified CPU recipe

[CMGS]

What changed

The CI image-build pipeline now boots the exact same firmware stack production uses (doctor.sh + the Go CLI): LongQT OpenCore, apt ovmf 4M firmware, and a single Skylake-Client-v4,vendor=GenuineIntel,kvm=on CPU.

• New scripts/lib-firmware.sh — extracts the validated ISO-download + qemu-nbd bake from doctor.sh into a self-contained bake_opencore_qcow2 OUT_QCOW2 (downloads the LongQT ISO, LONGQT_VER default v0.7, 384M qcow2, GPT+ESP via sgdisk, mkfs.fat -F32, copies EFI_RELEASE/EFI, with the blockdev-size + partition readiness waits and its own subshell-scoped temp-dir/trap cleanup). Privileged steps go through $SUDO so it works whether the caller is root (doctor) or an unprivileged CI runner with passwordless sudo.
• scripts/doctor.sh — now sources the lib and calls bake_opencore_qcow2; observable behavior (log lines, idempotency check, exit codes, root/deps/nbd checks) is unchanged.
• scripts/build-qemu-macos.sh —
  • OpenCore is baked into the workdir via the lib; every $OSX_KVM_DIR/OpenCore/OpenCore.qcow2 reference (boot/install/setup/slim/verify + configure_opencore) now points at the baked file. The qemu-nbd config.plist patch stays, applied to the baked image.
  • OVMF now comes from apt: /usr/share/OVMF/OVMF_CODE_4M.fd (read-only pflash) + a per-build writable copy of OVMF_VARS_4M.fd. OSX-KVM OVMF copies dropped.
  • -cpu replaced with exactly Skylake-Client-v4,vendor=GenuineIntel,kvm=on.
  • kholia/OSX-KVM is now cloned only for fetch-macOS-v2.py (recovery download); header comment updated.
• .github/workflows/build-macos-image.yml — added ovmf gdisk dosfstools parted to the apt install list (the bake now runs in CI and needs sgdisk/mkfs.fat/partprobe + the OVMF firmware).
• README.md — the "CI image pipeline" section now describes the LongQT + unified-CPU recipe and that CI boots the exact same firmware stack production uses.

Why one stack matters

Production already runs LongQT OpenCore; the OSX-KVM OpenCore does not boot on AMD Zen5, so the old pipeline validated golden images against a loader the hosts never run. Baking the same LongQT firmware in CI means an image that passes CI boots identically on the Intel/AMD hosts the CLI targets.

Display-resolution preservation

OSX-KVM's OVMF_VARS-1920x1080.fd pre-bakes a 1920x1080 GOP mode that the OCR click-through coordinates (fixed pixel positions) depend on; stock OVMF_VARS_4M.fd boots at the default resolution. To compensate, configure_opencore's plist patch now also sets UEFI>Output>Resolution="1920x1080". Verified against the LongQT v0.7 RELEASE config.plist: its UEFI>Output already has ProvideConsoleGop=True and Resolution="", so the patch touches only Resolution (all other Output keys preserved) and will take effect. A WHY comment documents this at the patch site.

Validation

• bash -n on all three scripts: pass.
• shellcheck -x on lib-firmware.sh + doctor.sh: clean. build-qemu-macos.sh has only pre-existing findings (SC2054/SC2034/SC2086/SC2015, identical set to origin/master), none introduced here; the $SUDO idiom is deliberately unquoted.
• Grep confirms no leftover OSX-KVM OpenCore/OVMF references in the build script (remaining OSX-KVM uses are the fetch-macOS-v2.py clone + the recovery/disk workdir only).
• Go gate (no .go files changed, run as a sanity no-op): gofumpt -l . clean, go build (darwin+linux) OK, golangci-lint (darwin+linux) 0 issues, go test -race OK.
• A real workflow_dispatch run is the follow-up validation and is still pending — no workflow was triggered as part of this PR.

🤖 Generated with Claude Code