rpk net tuner: ENA queue-index parse returns MaxInt (`-Tx-Rx-` not handled by the index regex)

Version

Present in v25.3.14 and on dev @ 3cfce474a872 (src/go/rpk/pkg/tuners/network/nic.go).

What happens

ENA names its per-queue interrupt vectors <dev>-Tx-Rx-<n> (hyphenated), e.g. from /proc/interrupts:

 288: ... ens5-Tx-Rx-0
 289: ... ens5-Tx-Rx-1

ENA is routed to the Intel parser. The fast-path detection pattern correctly includes the ENA form (nic.go:215 has both -TxRx- and -Tx-Rx-), so ENA IRQs are recognized as fast-path. But the index-extraction pattern only matches the Intel non-hyphenated form:

src/go/rpk/pkg/tuners/network/nic.go:248
    intelFastPathIrqPattern := regexp.MustCompile(`-TxRx-(\d+)`)

For an ENA -Tx-Rx-N name this does not match, so the queue index falls through to return MaxInt (nic.go:258). Every ENA queue index becomes MaxInt, making the live/dead cutoff zero.

Impact

The index-based sorting and live/dead cutoff logic no longer operate as intended (cutoff = 0). In the common case the final distribution may remain equivalent — ENA typically drops the names of inactive vectors, so when only named live vectors are present, an even spread can match what index-ordering would have produced. The bug matters when named inactive or mixed vectors are present, and in any case it leaves the behavior dependent on incidental IRQ ordering rather than the intended index order. Silent (no error surfaced).

Repro

On an ENA instance: grep -E 'Tx-Rx' /proc/interrupts shows -Tx-Rx-N vectors; the index parser (-TxRx-(\d+)) returns no match for them, so getQueueIndex returns MaxInt for every ENA queue in the net tuner's distribution logic.

Suggested fix

Extend the index regex to accept the ENA form, e.g. -Tx-?Rx-(\d+) (or add a -Tx-Rx-(\d+) alternative), matching the detection pattern at :215. Please also add an ENA-specific unit test (e.g. ens5-Tx-Rx-0 / ens5-Tx-Rx-1) so the two patterns can't drift again.