fix(firmware): route hotplug/notify acpi names through get_mimic_pci_name so macos loads the dsdt

docs/ANALYSIS.md

@@ -205,6 +205,28 @@ or device ID changes, so `DEVICES` / `PCI_VENDOR` / `CPU_HEURISTIC` are untouche
 Fix: drop the `ICH9_SATA1_DEV` hunk, leave SATA at stock `1f.2`. macOS boots on the default series;
 0/85 preserved.
 
+### CLEARED - the dangling ACPI name macOS aborts the DSDT on (folded into `01-firmware`)
+
+`01-firmware` renames the cold-plug PCI device ACPI nodes through `get_mimic_pci_name`
+(`build_append_pci_bus_devices`) to break the stock `S`+hex NameSeg signature. It left the hotplug
+and bus-notification code naming/referencing the *same* devices by the old `S%.02X` scheme, in four
+spots: the child-bridge `Scope` and `^S%.02X.PCNT` cross-reference in
+`build_append_notification_callback`, the `Notify()` target in `build_append_pcihp_notify_entry`,
+and the per-slot `Scope`/`Device` in `build_append_pcihp_slots`. So the DSDT opens `Scope(S13)` on a
+device actually declared `GFX3` - a dangling NameSeg.
+
+Only macOS exposes it. Its ACPI parser aborts the whole DSDT load on the missing name:
+`[S13_] Namespace lookup failure` -> `[DSDT] table load failed` -> `[\_SB.PCI0] ... AE_NOT_FOUND`,
+then it hangs in early IOKit (last line `AppleACPIPlatformExpert/cpus`). Linux and Windows swallow
+the `AE_NOT_FOUND` and boot on, which is why the identity guests never showed it - only a from-scratch
+macOS recovery boot did. Diagnosed with macOS IOKit verbose (`boot-args io=0xffffffff`).
+
+Fix (in `01-firmware`, alongside the `get_mimic_pci_name` definition it completes): route those four
+sites through `get_mimic_pci_name` so definitions and references agree. It *removes* `S%.02X`
+NameSegs rather than adding any, so the score is unaffected - re-measured on the rebuilt binary,
+VMAware v2.8.1 and HEAD both `detected=0`/`FIRMWARE=0`, and a Tahoe recovery boots to the installer
+GUI.
+
 ---
 
 ## CLEARED - CTYPE and SMBIOS_VM_BIT (the SMBIOS QEMU synthesises)