macOS: drive the install and all customization from a Recovery "PE", no GUI

Replace the screenshot/OCR/keystroke driving of Apple's Recovery with a
"PE": BaseSystem.dmg (a journaled HFS+ volume, writable from Linux) with one
LaunchDaemon added (makeRecoveryPE) that runs /Volumes/VMIX/run.sh as root at
boot, records the status and powers off. launchd loads it alongside its signed
cache (verified on Tahoe 26.6.2); same idea as AutoNBI/Imagr NetBoot images.

- makeImage: the PE runs vmix-install.sh (erase, installer app, SharedSupport
  pkgdmg, startosinstall). Progress is read from the serial console
  (boot-args serial=3 -v, VMIX-* markers) and screenshots (brightness only).
  Fully offline; prepare now takes ~5 min instead of ~10.
- customizeImage: boots the PE with the image attached and runs the template
  offline against the mounted System/Data volumes; OpenCore ScanPolicy
  restricted to HFS+/SATA so only the PE can boot. One PE boot ~30 s. The
  installed macOS is never booted for customization, so nothing depends on
  launchd/BTM approval or a first-boot agent (removed).
- templates rewritten for offline use: generalize creates the user with
  dscl -f (admin, home, auto-login kcpassword, Setup Assistant suppression,
  hostname, locale, timezone, keyboard type, container resize); remote-access,
  no-updates, performance edit the target's plists.
- makeBootDisk: build-time OpenCore variant (serial console, ScanPolicy).
- vm-driver.py rewritten: passive observation only (serial markers, kernel
  boots, panics, brightness), disk+serial-aware hang watchdog, reboot-death
  reset, halt/loginwindow detection. No OCR/tesseract.
- OpenCore: four SMBIOS DIMMs for MacPro7,1 (no "Memory Modules
  Misconfigured" warning).
- tools/soak.sh: repeatability harness.

Verified on daku: base install 23 min end to end; basic + generalize in three
~30 s PE boots; the result auto-logs into the desktop with the created user.

Root cause of the "first-boot hang" (from the serial log): the guest's restart
path panics (IOPlatformHaltRestartAction -> AppleSMC, SMCWDT smcWriteKey
kSMCBadCommand, nested panic) because the pinned OSX-KVM Lilu disables itself
on macOS 26, so VirtualSMC never loads. Handled by the driver (reset within
60 s); kext update to follow.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XsESshRCoBoUVWV9qKURUF

lib/images/macos/helpers/oc-config.py

@@ -43,6 +43,7 @@ def main():
     p.add_argument('--show-picker', default='true')
     p.add_argument('--timeout', type=int, default=2)
     p.add_argument('--extra-json', default='{}')
+    p.add_argument('--memory-mb', type=int, default=8192, help='VM RAM, described as 4 DIMMs')
     a = p.parse_args()
 
     with open(a.base, 'rb') as f:
@@ -84,6 +85,21 @@ def main():
     cfg['Misc']['Boot']['Timeout'] = a.timeout
     cfg['Misc']['Boot']['HideAuxiliary'] = True
     cfg['Misc']['Security']['ScanPolicy'] = 0
+    # MacPro7,1 firmware expects DIMMs in pairs (>= 4); with QEMU's single SMBIOS
+    # module macOS shows "Memory Modules Misconfigured" at every login. Describe
+    # the VM's RAM as four DDR4 modules instead.
+    if a.model.startswith('MacPro7'):
+        size = max(1024, a.memory_mb // 4)
+        cfg['PlatformInfo']['CustomMemory'] = True
+        cfg['PlatformInfo']['Memory'] = {
+            'DataWidth': 64, 'ErrorCorrection': 3, 'FormFactor': 9, 'MaxCapacity': 1536 * 1024 * 1024 * 1024,
+            'TotalWidth': 64, 'Type': 26, 'TypeDetail': 128,
+            'Devices': [{
+                'AssetTag': '', 'BankLocator': f'BANK {i}', 'DeviceLocator': f'DIMM{i + 1}',
+                'Manufacturer': 'Apple', 'PartNumber': f'VMIX{size}', 'SerialNumber': f'VMIX{i:04d}',
+                'Size': size, 'Speed': 2666,
+            } for i in range(4)],
+        }
     cfg['Misc']['Security']['SecureBootModel'] = 'Disabled'
     cfg['Misc']['Security']['AllowSetDefault'] = True
     cfg['Misc']['Debug']['Target'] = 0