fix(pci-ids): keep ich9 sata at 1f.2 so ovmf-booted guests find the disk

docs/ANALYSIS.md

@@ -105,7 +105,9 @@ Links, in order:
 5. ~~FACP C2/C3 latencies, vmaware.hpp:9242~~ - `0xfff` -> `0xffe`
 6. Debug Port OperationRegion at `0x0402` - already dead on this tree
 7. HPET register-validation loop - dormant, domain sets `hpet present='no'`. Re-arms if enabled.
-8. Dummy SATA, DMAR, APIC source overrides - already dead on this tree
+8. Dummy SATA, DMAR, APIC source overrides - dead on this tree (SATA at `1f.2`: see the SATA
+   subsection below - device 31's functions carry no generic `_ADR` node, so the `D0FA`+`0x1F0002`
+   pair never forms)
 
 Link 3 requires **all four** of `LNKE`, `LNKH`, `GSIE`, `GSIH`, which is QEMU's eight-link plus
 eight-GSI layout. Real boards have four PCI link devices and no GSI-named ones, so rename the
@@ -181,6 +183,28 @@ Verified on QEMU 11.1.2 with this fix in the default series: the DSDT keeps `\_S
 login and powers off via S5 in ~12 s; VMAware v2.8.1 and HEAD both report `detected=0` / `FIRMWARE=0`
 on the stealth guest; Windows (secboot + SMM) and Linux boot unchanged. The opt-in split is gone.
 
+### CLEARED - the SATA controller OVMF must find at 1f.2 (`03-pci-ids`, 1.4.1)
+
+`03-pci-ids` originally relocated the ICH9 SATA controller off its standard slot
+(`ICH9_SATA1_DEV` 31 -> 20) to move the dummy-SATA DSDT node away from `00:1f.2`. That breaks
+OVMF first-boot for any SATA-booted guest: OVMF expects the q35 AHCI at `00:1f.2`, so with it at
+`00:14.2` OVMF never builds the disk boot option and falls through to `Start PXE over IPv4`. Only
+macOS exposed this - it boots OpenCore off AHCI; the Windows identity guests boot from NVMe and
+never touched the moved controller. A/B confirmed it: stock QEMU reaches the OpenCore picker, the
+1.4.0 patched binary PXEs, and restoring `ICH9_SATA1_DEV = 31` reaches the picker again
+(`BdsDxe: loading ... from PciRoot(0x0)/Pci(0x1F,0x2)/Sata`).
+
+The relocation was never load-bearing for the score. The dummy-SATA FIRMWARE link
+(vmaware.hpp ~9963) fires only on **both** the NameSeg `D0FA` **and** `Name(_ADR, 0x001F0002)`.
+With SATA back at `1f.2`, neither is present: QEMU describes device 31's functions under the ICH9
+LPC/ISA scope, not through `build_append_pci_bus_devices`, so the controller gets no generic
+`_ADR` node at all, and `get_mimic_pci_name` never emits `D0FA` for any devfn. Dumped the DSDT of a
+`1f.2`-SATA guest on the fixed build: zero `D0FA`, zero `08 5F 41 44 52 0C 02 00 1F 00`. No vendor
+or device ID changes, so `DEVICES` / `PCI_VENDOR` / `CPU_HEURISTIC` are untouched.
+
+Fix: drop the `ICH9_SATA1_DEV` hunk, leave SATA at stock `1f.2`. macOS boots on the default series;
+0/85 preserved.
+
 ---
 
 ## CLEARED - CTYPE and SMBIOS_VM_BIT (the SMBIOS QEMU synthesises)