Fix realtime buffer-growth violation in audio callback

[yuumarealzxlys]

Summary

• scratch_multi was resize()'d on the audio thread every block for multi-out bridged plugin inserts — a real-time-safety violation (buffer growth in the audio callback). Fixed by pre-reserving its capacity on the control thread in resolve_bridge_sinks, so the audio-thread resize never reallocates, while keeping the exact .len() invariant scatter_vsti_output_children depends on to recover the channel stride.
• Removed redundant manual zero-loops in the cpal (Linux ALSA / macOS CoreAudio / Windows WASAPI Shared / ASIO), WASAPI Exclusive, and WDM-KS output callbacks — fill_output_f32 already overwrites every sample of its output slice on every reachable path, so the pre-zero was dead work every block.
• Clamped (instead of grew) a defensively-sized scratch buffer in the WASAPI Exclusive path for the same reason (provably unreachable in practice, but still violated the no-growth rule as written).
• Unrelated one-line fix: vst2_processor.cpp was missing #include <dlfcn.h>, which broke the whole crate's build on Linux (pre-existing on main, unrelated to the buffer work — included only because it blocked verifying everything else).

Test plan

• cargo test -p sphere_directaudioengine --lib — 236 passed, including vsti_output_children_scatter_demuxes_channel_pairs (the test that depends on the scratch_multi.len() invariant)
• cargo check --workspace — clean
• cargo fmt -p sphere_directaudioengine -- --check — clean
• wasapi_exclusive.rs / wdm_ks.rs are Windows-only and could not be compile-checked or runtime-tested on this Linux machine — needs a Windows build/runtime check before merge