Handle microphone init failure without aborting

[ferologics]

Summary

This PR prevents a hard crash when microphone stream initialization fails (for example, when Windows microphone privacy blocks access).

What changed

• src-tauri/src/audio_toolkit/audio/recorder.rs
  • Replaced panic paths in AudioRecorder::open (expect/unwrap/panic) with explicit error propagation.
  • Added a startup handshake channel so open() only succeeds after worker initialization succeeds.
  • Converted known permission-denied errors into a clearer user/actionable message.
• src-tauri/src/actions.rs
  • When recording fails to start, immediately restore UI state by hiding the recording overlay and setting tray icon back to idle.

Why

In release builds (panic = "abort"), panic paths during recorder startup can terminate the process. This keeps startup failure as a normal error path instead.

Refs #436

[cjpais]

@ferologics have you tested this yourself to verify?

Just want to make sure. Also do you know if the UI visibly says anything about this failure case?

[ferologics]

@cjpais i wasn't able to make handy run locally from source (ref) so i couldn't test.

I came across the crash due to having disabled microphone globally via settings.

Tried to make this change isolated to that, not touching any UI. Onboarding / in-app hints about disabled mic could made be better tho.

Right now when the crash happens it briefly shows the recording UI and then it disappears, no info in the app / anywhere about it.

[ferologics]

re: the microphone access denied bit -- it comes directly from my local agent. i had it check the crash log, look at current system settings configuration and patch that particular case in handy.

[cjpais]

Got it, I am going to push some changes for the UI I think. Let's get your build env fixed