Target the actual NVMe controller in Apple suspend fix

[Drecullith]

Summary

Fix the Apple NVMe suspend workaround so it targets the actual NVMe PCI controller instead of assuming it is always 0000:01:00.0.

On MacBook models with discrete graphics, including MacBookPro13,3, PCI 01:00.0 can be the dGPU while the NVMe controller is at another address such as 02:00.0.

The previous guard only checked whether 01:00.0 exposed d3cold_allowed. Since that attribute is available on other PCI devices too, the installer could successfully disable D3cold on the GPU while leaving the NVMe untouched.

This change:

• resolves the installed NVMe controller through /sys/class/nvme;
• validates the resolved device name as a PCI BDF before using it;
• requires the resolved PCI device to expose d3cold_allowed;
• writes the discovered NVMe path into omarchy-nvme-suspend-fix.service;
• reloads systemd after updating the unit;
• detects the previous Omarchy unit before undoing its legacy 01:00.0 setting;
• restores D3cold on that legacy target only when the actual NVMe is elsewhere and the existing Omarchy service proves it contained the old hard-coded path.

Fixes #10826.

Tests

Added test/shell.d/apple-nvme-suspend-test.sh covering:

• an NVMe controller at 0000:02:00.0 is discovered correctly;
• non-PCI controller paths are rejected;
• a controller without d3cold_allowed is rejected;
• the generated systemd unit uses the discovered NVMe device;
• legacy D3cold restoration is gated on both a different actual NVMe address and the old Omarchy unit.

The focused regression tests pass locally.

Also verified:

• bash -n install/hardware/apple/fix-suspend-nvme.sh
• bash -n test/shell.d/apple-nvme-suspend-test.sh
• the generated systemd unit passes systemd-analyze verify

No physical MacBook hardware test was available in this environment.