feat(windows): implement out-of-process VST3 plugin hosting and GUI isolation

[yungchoppa]

What does this PR do?

On Windows, hosting VST3 plugin GUI editors in-process inside Tauri 2 (WebView2 / Tao event loop) resulted in immediate access violations (0xC0000005) or frozen GUI timers due to DirectComposition and message loop conflicts with Chromium.

This PR implements an Out-of-Process Plugin Bridge for Windows:

• Runs an isolated lightweight helper process (splitwave.exe --plugin-bridge <session_id>) hosting the plugin in a pure Win32 message loop without any WebView2/Tao interference.
• Implements lock-free low-latency (<0.1ms) SPSC audio exchange over Windows Shared Memory (CreateFileMappingW / MapViewOfFile) with atomic sequence synchronization.
• Adds safe bi-directional parameter automation and editor lifecycle management (hide/show re-use without COM teardown churn).
• Fixes premature IPlugView deallocation in has_editor.

Why is this the right approach?

Professional DAWs on Windows (Bitwig, Reaper, FL Studio) host plugins out-of-process to achieve a Zero-Crash Guarantee. In-process hosting fundamentally conflicts with WebView2's message hooks and COM memory allocator. The bridge provides full crash isolation: even if a third-party plugin misbehaves, the main Splitwave audio engine continues uninterrupted.

No external dependencies are introduced — it only enables the Win32_System_Memory feature on the existing windows crate.

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 — all must pass and leave the tree clean
• Generated TS types are committed with the Rust change (if any)
• No new dependency without a reason in the PR description
• I read the RT audio path section of docs/CONCEPT.md and confirmed this change adds no allocations, locks, or syscalls to cpal / SCK callbacks or DspWorker::run

Platform coverage

• Developed on: Windows 11
• Tested on: Windows 11
• What I did to test:
  • Tested with complex JUCE VST3 plugins (e.g. TDR Nova).
  • Verified audio DSP throughput, 60fps real-time UI spectrum analyzer rendering, parameter automation, and repeated open/close cycles (>10x).
  • Verified clean slot destruction and pipeline stoppage without crashes.
• Not tested: Linux / macOS (all new logic is strictly guarded under #[cfg(target_os = "windows")]).

Does this change touch any per-OS file?
Changes are strictly isolated under #[cfg(target_os = "windows")] in src-tauri/src/audio/plugins/bridge/, registry.rs, editor.rs, vst3_host.rs, and helper dispatch in main.rs/lib.rs. macOS and Linux backends remain completely untouched.

Related

• Closes [crash] VST3 editor deadlocks and crashes via Tao/WebView2 conflict #35