Voice dictation permanently freezes TUI: main thread blocked in synchronous CoreAudio call (AudioUnitSetProperty) while opening microphone

## Summary

Holding Space to start voice dictation permanently freezes the entire TUI: the footer stays on "keep holding…" forever, no keystroke is processed, Ctrl+C does not recover, and the only way out is killing the process. `sample` shows the **main thread blocked in a synchronous CoreAudio call with no timeout** while opening the microphone. When the audio HAL is slow to respond (a third-party audio client had degraded `coreaudiod` state), that call never returns and the whole input loop dies with it.

This looks like the root cause behind #20476 (closed), which described the same symptom without a stack trace.

## Environment

- Claude Code 2.1.226 (native build, `claude.exe` via Homebrew)
- macOS 26.6.2 (25G83), Apple Silicon (arm64)
- Terminal.app, hold-to-talk mode (default Space binding), claude.ai account

## Stack sample of the frozen process

100% of samples (1674/1674) on the main thread, blocked here:

```
1674 Thread DispatchQueue_1: com.apple.main-thread (serial)
... claude.exe frames ...
??? (in .5ed67dedd7cb7578-0.node) <- bundled native audio module
??? (in .5ed67dedd7cb7578-0.node)
AudioUnitSetProperty (in AudioToolboxCore) + 484
??? (in CoreAudio)
??? (in CoreAudio)
??? (in CoreAudio)
AudioDeviceGetProperty (in CoreAudio) + 204
HALPlugIn::ObjectHasProperty(HALObject const&, AudioObjectPropertyAddress const&) const + 44
HAL_HardwarePlugIn_ObjectHasProperty(AudioHardwarePlugInInterface**, unsigned int, AudioObjectPropertyAddress const*) + 480
```

The process sits in `AudioUnitSetProperty → AudioDeviceGetProperty → HALPlugIn::ObjectHasProperty` indefinitely (observed >10 minutes, 0% CPU, state S). Since this runs on the same thread that services terminal input, the TUI freezes completely — matching the "no spinner, completely unresponsive" reports in #20476.

## Controlled reproduction

The freeze correlates with degraded CoreAudio daemon state caused by a long-running third-party audio client (an app with a per-app volume mixer that inserts itself into CoreAudio; `coreaudiod` had accumulated 10+ hours of CPU time). Space key hold was simulated with synthetic CGEvents carrying the autorepeat flag, so all three tests are identical at the input layer:

| Test | Conditions | Result |
|---|---|---|
| A | third-party audio-mixer app running for ~2 weeks | **permanent freeze**, stack above |
| B | no third-party audio clients | dictation works end-to-end (mic opens, transcribes, inserts) |
| C | same app freshly relaunched | dictation works — the bad HAL state builds up over time |

So the external app is the *trigger*, but the *defect* is in Claude Code: a hostile-or-slow audio HAL should never be able to hang the input loop.

## Expected behavior

- Open the audio device asynchronously (or on a worker thread) with a timeout.
- On timeout, cancel dictation, show an error ("microphone unavailable"), and keep the TUI responsive.

## Workarounds found

- `claude --continue` after killing the frozen process restores the session.
- Quitting/relaunching the offending audio client (or disabling its mixer feature) clears the HAL state and dictation works again.

Happy to provide the full `sample` output or run an instrumented build if useful.

Start from the voice dictation path that opens the microphone when Space is held in the TUI, especially the bundled native audio module shown in the sample. Reproduce on macOS and use sample output around AudioUnitSetProperty to confirm the main thread blocks. Done means a slow CoreAudio/HAL call times out or runs off the input loop, dictation shows an error, and the TUI remains responsive.

索引モデルが issue の本文から書いたものです。