fix(amd): name consumer Radeons instead of showing their PCI device ID

[apollo-mg]

Branched off main, so it's independent of #1 — no file overlap, either can merge first.

The bug

The sysfs collector reports an RX 9070 XT as "AMD GPU 7550".

/sys/class/drm/cardN/device/product_name is an Instinct/Pro field. Consumer Radeons don't populate it — the file is absent, not empty — so parseSysfs never sets a name and the uevent fallback prints the second half of PCI_ID=1002:7550. This hits every consumer AMD card. All the telemetry around it is correct, which makes the label look odder than it is.

Why a lookup table can't fix it

1002:7550 is shared by the RX 9070, the 9070 XT and the 9070 GRE — that's why pci.ids lists all three on one line:

7550  Navi 48 [Radeon RX 9070/9070 XT/9070 GRE]

No device-ID table can tell you which board you have, however current it is. rocm-smi is the only thing on the machine that knows:

Card Series:  AMD Radeon RX 9070 XT      <- the answer
Card Model:   0x7550                     <- what we were showing

The fix

parseRocmSmi already read Card Series — it just threw away PCI Bus. It now keeps it as pciBus, and amd-names.js joins rocm-smi's cards to the sysfs cards on that bus.

The bus join is the load-bearing part. rocm-smi enumerates from card0; DRM numbering is sparse. On the box this was found on, the only GPU is /sys/class/drm/card1 and rocm-smi calls it card0. Joining on the cardN key or on array position would put the wrong name on the wrong card — exactly the sparse-numbering case amd-sysfs.js already carries a comment about ("a real capture had a lone GPU at card1").

The two-card fixture in the test pins this down: it reverses rocm-smi order against DRM order and fails if either name lands on the wrong card.

Cost and failure behaviour

• One extra rocm-smi call per host, cached forever after — marketing names are static. Narrower flag set than ROCM_CMD (--showproductname --showbus only) so it stays well clear of the --showallinfo abort path you documented.
• enrich() skips the call entirely when every card already has a real name, so Instinct/Pro hosts never pay for it.
• Failure is always silent. rocm-smi missing, or present and aborting — which this repo has already met on real hardware — resolves to an empty map and the ID-based name stands. A naming fix must not be able to take a host offline, so nothing here ever rethrows.

Verification

On the card in question: AMD GPU 7550 → AMD Radeon RX 9070 XT, telemetry byte-for-byte unchanged around it.

BEFORE: AMD GPU 7550           uuid=AMD-0000:2d:00.0
AFTER:  AMD Radeon RX 9070 XT  uuid=AMD-0000:2d:00.0
        util=8% vram=3471/16304MiB temp=36C power=60W clk=2026MHz

10/10 test files passed, 15 new assertions.

K=1 on real hardware — I have one AMD GPU, so the multi-card bus join is covered by the synthesized fixture only, not by a real two-card box. Worth saying plainly since that's the part most likely to matter to someone else.

Deliberately not included

A pci.ids fallback for hosts that have amdgpu but no ROCm installed — probably the common case for gaming rigs. It would turn "AMD GPU 7550" into "Radeon RX 9070/9070 XT/9070 GRE", which is better but still can't name the board, and it needs a 1.5 MB file parse with distro-dependent paths that don't exist on your primary Windows target. Happy to add it as a follow-up if you want the breadth; I left it out to keep this reviewable.

[an80sPWNstar]

Merged, and shipped as v0.3.14 with a full set of installers — thanks for the fix and for the write-up, the bus-join reasoning and the K=1 caveat made this an easy review. The only thing added on top was pinning ROCM_NAME_CMD off the OD-clock crash path in real-hardware.test.js, same guard the main query carries. On the pci.ids fallback: agreed it's better left out for now; if a no-ROCm gaming-rig report ever comes in, that's the moment to revisit it.