Build 4f2ad65 wired the Speaker button to AudioManager.setSpeakerphoneOn
but user testing found that flipping speakerphone on an active Oboe
VoiceCommunication stream silently tears down the AAudio streams on
Pixel-class devices — both capture and playout stop producing data.
Only ending the call and rejoining brings audio back (because the fresh
Oboe open runs with the new routing already applied).
Also the earpiece state showed up red in the UI because the button was
getting the `.muted` CSS class when speakerphoneOn=false. Earpiece is a
valid routing state, not a muted one.
Fix set_speakerphone Tauri command:
1. Flip AudioManager.setSpeakerphoneOn via JNI (as before).
2. If the Oboe backend is currently running, stop it, sleep 50 ms to
let AAudio finalise the transition, then start it again. The Rust
send/recv tokio tasks keep running across the gap — they just read
zero samples and write into the preserved ring buffers for a few
frames, which is acceptable. The AudioBackend singleton's ring
state is preserved across stop+start because it's in a 'static
OnceLock.
3. Debounce the UI click via speakerphoneBusy + spkBtn.disabled so
users can't queue up multiple toggles during the restart window.
Fix main.ts Speaker button:
- Remove the `.muted` classList toggle (added `.speaker-on` for CSS).
- Update label text to "🔊 Speaker" / "🔈 Earpiece" for clarity.
- On showCallScreen(), invoke is_speakerphone_on to sync the label
with the real AudioManager state, so it matches reality after a
rejoin (which was another symptom the user hit — the button label
desynced from the actual routing after ending and restarting a
call).
- Debounce click + disable button while the restart is in flight.
Drops #[allow(dead_code)] from wzp_native::audio_is_running now that it
is actually called from the set_speakerphone restart guard.
4c6aac654a