[Horuse]

What does this PR do?

Moves device and volume commands off the main thread: list_input_devices, list_output_devices, device_info, get_device_volume, watch_device_volume, unwatch_device_volume, set_device_volume.

Tauri runs sync commands on the main thread. On Windows these go through WASAPI (endpoint enumeration, IAudioClient activation), which can stall for seconds. Device nodes poll device_info every 2.5 s, so opening or starting a pipeline froze the window, up to "Not responding". The audio threads kept running, which matches the report in #68.

Why is this the right approach?

Same pattern as audio_request and read_file_peaks: spawn_blocking through a small off_main helper. The frontend API is unchanged. The volume watch code already expects MTA threads (ensure_com), and the blocking pool gives it that, unlike the STA main thread.

Checklist

• Diff is limited to the change, no unrelated edits
• bun run check passes
• cargo check --manifest-path src-tauri/Cargo.toml passes
• bun run format leaves the tree clean
• Generated TS types are committed with the Rust change (none)
• No new dependency
• No changes to the RT audio path

Platform coverage

• Developed on: macOS
• Tested on: macOS (cargo check)
• What I did to test: build check only
• Not tested: Windows, Linux

Only commands.rs changes; the per-OS backends are untouched. On every platform these commands now run on the blocking pool instead of the main thread.

Related

• Refs [bug] App stutters and crashes when loading existing presets #68