fix(audio): report and handle capture/session startup failures

[erning]

Summary

When audio capture failed to start (e.g. device disconnection, format incompatibility), the app silently continued with the UI stuck in "recording" state and a Rust session waiting for audio that would never arrive. The user would eventually see a delayed "no speech recognized" error with no indication of the actual cause.

Return value propagation:

• startCaptureWithAudioCallback: now returns BOOL instead of void; callers check the result and call handleAudioCaptureError: on failure
• beginSessionWithMode: now returns BOOL; callers abort before starting audio capture if the Rust session fails to create
• startAndReturnError: result is checked directly instead of relying on NSError being non-nil

Session cleanup:

• handleAudioCaptureError: uses cancelSession instead of endSession — endSession only closes the audio channel, letting the session process empty input and emit a spurious "no speech recognized" error; cancelSession sets the cancelled flag so the session aborts cleanly

Error display protection:

• Added showingError flag to prevent Rust-side state changes (cancelled, idle, failed) from overwriting the 2-second error display in both handleAudioCaptureError: and rustBridgeDidEncounterError:
• Flag is cleared when a new session starts (hold/tap), preventing it from getting permanently stuck if the user retries within the error window

Test plan

• xcodebuild passes
• Disconnect audio input device, press hotkey — error notification appears and stays visible for 2 seconds
• Immediately retry after error — new session starts normally, no stuck state
• Trigger a Rust-side error (e.g. ASR connection failure) — error display stays for 2 seconds without flickering