Handle NVMe devices behind bridges

[hoshinolina]

NVMe devices behind USB bridges/etc might use a different interface, but still report the protocol as "NVMe". Also collect stats from those.

[hoshinolina]

Fixed the DCO.

[thomasbarton]

I use Samsung T7 SSDs with Raspberry Pi 4s, and the metric I wanted from this exporter is smartctl_device_percentage_used — the NVMe wear level.

The three drives:

model	capacity	firmware	smartctl device type
Samsung Portable SSD T7	500 GB	FXG41P2Q	sntasmedia
Samsung Portable SSD T7	500 GB	FXG42P2Q	sntasmedia
Samsung Portable SSD T7 Shield	1 TB	FXI72P2Q	sntasmedia

There were no errors anywhere — the exporter reported the correct device count and smart_status of 1. The wear metric was just absent.

The bug: the exporter detects these drives as NVMe, but does not collect the NVMe metrics, because they sit behind a USB bridge. smartctl reports both facts separately:

"device": { "type": "sntasmedia", "protocol": "NVMe" }

device.type is the bridge; device.protocol is the drive. The check at smartctl.go:105 tests interface_, which carries device.type, so mineNvme* is skipped. The exporter has already worked out that the drive is NVMe, and publishes it as a label on the same series whose NVMe metrics it drops:

smartctl_device{device="usb-Samsung_PSSD_T7_<REDACTED>-0:0", interface="sntasmedia", protocol="NVMe", serial_number="<REDACTED>"} 1

SMARTDevice.protocol is parsed at smartctl.go:80 and then never used.

I built master with this PR applied and ran it against the drives. It works:

smartctl_device_percentage_used{device="usb-Samsung_PSSD_T7_<REDACTED>-0:0"} 5
smartctl_device_available_spare{device="usb-Samsung_PSSD_T7_<REDACTED>-0:0"} 100

#279 reports the same failure on a Realtek bridge (sntrealtek), and its author wondered whether special-casing the type was a good idea long term. This PR answers that: matching device.type means enumerating bridge vendors forever — sntasmedia, sntrealtek, sntjmicron, and whatever ships next — while device.protocol is the field smartctl already normalises. Every NVMe drive in a USB enclosure is affected today, and this fixes all of them at once.

Environment: exporter master @ 123f6f2 (linux/arm64), smartmontools 7.5, alpine 3.24.1.

(I used AI to help write this comment)