Porting the iOS recorder fix back the other way, and the same bug was here.
`MediaRecorder.prepare()` and `start()` acquire the microphone, and acquiring
hardware blocks. `startRecording` was a plain function called straight from the
UI, so that happened on the main thread — as did `File.createTempFile` beside
it. `cancelRecording` released the recorder the same way.
⚠️ **The tell was the inconsistency.** `stopAndSendRecording` already went
through `withContext(Dispatchers.IO)`, so someone had thought about this for
stopping and not for starting — and starting is the half that waits for the
audio route to come up. On iOS the identical mistake froze the main thread for
SIXTY SECONDS on a simulator; here it did not misbehave on the emulator, which
is not the same as being correct on a device whose audio route is busy.
All three paths now agree. The UI state on cancel is cleared immediately rather
than after the hardware is handed back, because the user pressed Cancel and
should not watch the bar linger.
Verified on the emulator: recording still starts (timer ticking at 8.4s),
cancel still stops it and the composer returns, app alive throughout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
