rpk redpanda tune net: `--output-script` still mutates NIC channel count (SetChannels bypasses the script executor)

Version

Present in v25.3.14 and on dev @ 3cfce474a872 (src/go/rpk/pkg/tuners/net_tuners.go:218).

What happens

rpk redpanda tune net --output-script <file> is expected to generate a tuning script without applying anything. But the RX/TX queue-count tuner calls ethtool.SetChannels(...) directly instead of routing through the executor abstraction that --output-script relies on:

src/go/rpk/pkg/tuners/net_tuners.go:218
    _, err = f.ethtool.SetChannels(nic.Name(), targetChannels)

The other listed net-tuner mutations go through f.executor.Execute(...) (e.g. :341, :356, :479, :521, :573), which under --output-script renders to the file instead of executing. Because :218 bypasses the executor, the channel change is applied to the live NIC even in script-render mode, and the generated script contains no corresponding ethtool -L line. (A renderable command, NewEthtoolSetChannelCmd, exists but appears to be unreferenced/dead code.)

Impact

Operators using --output-script as a safe "see what it would do" dry-run on a running host can have the NIC's combined queue count silently lowered — on AWS ENA this triggers a device close/open (ring teardown) — with no indication in the emitted script. Fires when: net tuning enabled, driver supported (incl. ena), and current channels > target (e.g. dedicated mode with a reduced cores_per_dedicated_interrupt_core).

Repro

⚠️ This repro mutates the NIC — run on a disposable/test host only, not a production node.

1. On a supported NIC where current channels > target, enable the path that lowers channels: set rpk.tune_network: true and enable dedicated mode (rpk.allow_dedicated_interrupt_mode: true with a cores_per_dedicated_interrupt_core that yields fewer interrupt CPUs than the current channel count). Note: rpk redpanda mode prod alone may leave MQ selected, which does not trigger channel lowering.
2. ethtool -l <nic> (note combined count).
3. rpk redpanda tune net --output-script /tmp/plan.sh
4. ethtool -l <nic> → combined count is changed; grep -c 'ethtool -L' /tmp/plan.sh → 0.

Suggested fix

Two levels:

• Immediate (safety): when --output-script (lazy/script-render mode) encounters a required channel change, fail clearly rather than silently applying it — so the "dry run" never mutates the NIC.
• Complete: route the channel change into the generated script, but note this is more than rendering an ethtool -L line: the subsequent IRQ/RPS/queue discovery currently inspects live NIC state, so it would compute downstream commands against the old (pre-change) topology while the script defers the change. A correct implementation must defer post-channel discovery until script execution so the rendered downstream commands reflect the resulting topology.