fix: detect Strix Halo by AMD PCI id

[hogeheer499-commits]

Summary

• map AMD PCI device 1002:1586 to Strix Halo [Radeon 8060S]
• use the mapping for both sysfs and lspci -mm -nn fallback detection
• add regression coverage for both Linux probe paths

This addresses one of the PCI-ID follow-ups in #36.

Real hardware reproduction

Tested on a Beelink GTR9 Pro with a Ryzen AI MAX+ 395 / Radeon 8060S. On current main, Linux exposes the GPU as generic PCI device 1586, so whichllm hardware reported:

GPU 0: Device 1586 — 512 MB — BW: N/A

With this patch, the same machine reports:

GPU 0: Strix Halo [Radeon 8060S] — shared memory — BW: 256 GB/s

The 512 MB aperture is then normalized correctly instead of being treated as dedicated VRAM. The mapping also activates the existing Strix Halo shared-memory and bandwidth logic; it does not add a new performance heuristic.

The reproduction machine is the primary system used for the public AMD Strix Halo Local LLM Guide.

Validation

• uv run --locked ruff check .
• uv run --locked ruff format --check .
• uv run --locked pytest (471 passed)
• live whichllm hardware check on the affected Ryzen AI MAX+ 395 system

[Andyyyy64]

sorry this took me so long to review

thanks for including the real-hardware reproduction — the parser change and the shared-memory path look good. there's one thing blocking the merge:

1002:1586 isn't unique to the Radeon 8060S. the current pci.ids entry is Strix Halo [Radeon Graphics / Radeon 8050S Graphics / Radeon 8060S Graphics], so mapping every generic 1586 device to Strix Halo [Radeon 8060S] would mislabel 8050S systems.

could you use a SKU-neutral name such as Strix Halo [Radeon Graphics] or the canonical combined label, and update the assertions to match? it will still activate the existing Strix Halo shared-memory and 256 GB/s paths.

the Actions runs are currently action_required and didn't start, so we'll also need the locked lint and test checks to run after the update.