Title: ATU button always triggers tune/retune instead of toggling to bypass on second click

What happened?

When clicking the ATU button in AetherSDR's TX applet, the radio correctly initiates a tune cycle. However, clicking the ATU button a second time on the same frequency — instead of placing the internal tuner into bypass — appears to issue a forced full retune command. This means there is no way to bypass the internal ATU from the AetherSDR UI without navigating to another interface.

In SmartSDR (SSDR), the ATU button behaves as a toggle: the first click on a given frequency triggers a tune cycle, and a second click on the same frequency (when a valid tune solution is already stored/active) switches the internal tuner to bypass mode. AetherSDR does not replicate this toggle behavior.

What did you expect?

The ATU button should mirror SmartSDR's behavior:

• First click: Issue a tune command (atu tune) — radio runs a tune cycle, finds a match network solution, and the ATU status transitions from tuning → tune_good (or equivalent).
• Second click (same frequency, ATU already tuned): Toggle the internal tuner into bypass (atu bypass) rather than triggering another tune cycle. The ATU status indicators in the TX applet should update to reflect the bypass state.

Alternatively, if a clean toggle is not feasible given the protocol state machine, a separate dedicated BYPASS button or a two-state toggle button (TUNE / BYPASS) should be added to the TX applet so that the user can explicitly place the ATU in bypass without re-tuning.

Steps to reproduce

1. Connect AetherSDR 0.8.22 to a FLEX-6600 running firmware 4.1.5.39794.
2. Open the TX applet in the AppletPanel.
3. Set a transmit frequency and ensure the ATU is not already in bypass.
4. Click the ATU button — observe that a tune cycle begins (expected).
5. Wait for the tune cycle to complete (ATU status indicators show tune complete).
6. Without changing frequency, click the ATU button again.
7. Observe that a second tune cycle is triggered (forced retune) rather than the ATU being placed into bypass.

Expected at step 7: The ATU should enter bypass mode, consistent with SmartSDR behavior.

Radio model & firmware

• Radio: FLEX-6600
• Firmware: 4.1.5.39794

OS & version

• OS: Windows
• AetherSDR version: 0.8.22
• Qt version: 6.7.3

Developer Notes

Relevant source files:

• src/models/TransmitModel — This is the authoritative location for internal ATU state. The model should be tracking the current ATU status (e.g., tuning, tune_good, bypass, not_present) as received via S<handle>|atu ... TCP status messages (subscribed via sub atu all during the connection sequence). The ATU command logic — specifically what is sent when the ATU button is clicked — almost certainly lives here or is dispatched from here via commandReady().

• src/gui/TxApplet — This is where the ATU button widget lives and where its clicked signal is connected. The button handler needs to inspect the current ATU state from TransmitModel and branch: if the tuner is in an active/tuned state, send atu bypass; if in bypass or no solution stored, send atu tune. Currently it appears to unconditionally send atu tune (or possibly atu tune force=1 on repeat clicks), ignoring existing state.

Likely root cause:

The ATU button's click handler in TxApplet is probably unconditionally emitting atu tune (or a forced variant) every time, without consulting the current ATU status held in TransmitModel. The fix requires:

1. Ensuring TransmitModel correctly parses and stores the ATU status field from S<handle>|atu status=<value> status messages — confirm the exact key name from a Wireshark/API log (see logging below).
2. Updating the TxApplet ATU button handler to read TransmitModel::atuStatus() (or equivalent) at click time and conditionally send either atu tune or atu bypass.
3. Updating the ATU button's visual state (checked/unchecked or label text) to reflect the current status, so the user can see whether clicking will tune or bypass.

Note on optimistic updates: If the radio does not echo an ATU status change back via a status message after atu bypass (similar to the tnf remove case documented in CLAUDE.md), an optimistic update to TransmitModel will be required, and a separate GitHub issue should be filed against FlexRadio requesting proper atu status feedback per the project's documented policy.

Logging to enable for diagnosis:

Enable the following in Help → Support before reproducing:

• Protocol / Command — to capture the raw C<seq>|atu ... commands being sent on each button click and verify whether atu tune vs atu bypass is being issued.
• TX / Transmit — to see how TransmitModel is interpreting the incoming S<handle>|atu ... status messages.

A Wireshark capture on TCP port 4992 filtered to atu strings would also conclusively show what commands AetherSDR is sending vs. what SmartSDR sends under the same click sequence, and reveal the exact key=value format of ATU status messages from this firmware version.

support-bundle-20260425-215938.zip