[Linux] Tray application not switching listening nodes reliably

App version

linux-v0.1.0

Variant

Rust rewrite (linux-rust branch)

Distro and version

CachyOS

Desktop environment / compositor

KDE Wayland

Install method (only official sources)

Built from source (nix or otherwise)

AirPods model

AirPods Pro 3

What happened

When switching the listening mode from the tray application, clicking a radio button occasionally gets stuck — the new button appears checked but the mode does not actually change. When this happens, multiple radio buttons can appear checked simultaneously.
I have not been able to reliably reproduce the stuck state, but it has happened twice. A related behavior I can consistently reproduce is that even during a successful mode switch, there is a brief moment where two radio buttons appear checked at the same time before the UI settles. This suggests the UI state and the underlying mode state may not be updated atomically, which could be contributing to the stuck state.
Steps to reproduce (stuck state):

Open the tray application
Click a radio button to switch listening mode
Occasionally, the button appears checked but the mode does not change and multiple buttons can be checked simultaneously

Expected behavior: Clicking a radio button switches the listening mode and only one button is ever checked at a time.
Observed behavior: Transient double-check visible even on successful switches; occasionally the UI gets stuck with multiple buttons checkable and the mode not

edit: added screenshot

Start with the Linux Rust tray application's listening-mode radio-button handling and reproduce the transient double-check or stuck state on KDE Wayland. Trace how the selected UI state and underlying listening mode are updated during a switch, then verify that successful switches leave only one button checked and actually change the mode.