The microphone pipeline is purely singleton — when a toggle action (start/stop recording) is already in progress, there is no point queuing additional ones. Rapid presses caused threads to pile up waiting on the state mutex while the first press held it during blocking audio device I/O, freezing the app.

Add an AtomicBool guard that rejects concurrent toggle presses while an action is in-flight.

Before Submitting This PR

• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

Human Written Description

Sometimes when I push to talk the UI doesn't appear immediately. I press again because I think I missed the button, etc. Eventually I've pressed a few times and the app has locked up. I have to kill via the Activity Monitor.

Related Issues/Discussions

No existing issue found — this is a new bug report via PR.

Testing

Could not fully test the dev build due to macOS TCC refusing accessibility permissions for ad-hoc signed debug binaries. The fix is 6 lines and correct by inspection — the AtomicBool CAS guard is a standard pattern for preventing re-entrant calls to a singleton resource.

AI Assistance

• AI was used (please describe below)

If AI was used:

• Tools used: Claude Code
• How extensively: AI investigated the root cause (traced the full shortcut → audio manager mutex chain), identified the deadlock pattern, and wrote the fix. Human identified the bug from real usage and directed the approach.