v3.9.1: plain/WASAPI streams now play on an ASIO-mode receiver (silent-mic fix)

Receiver: a Mixed (plain) session is rendered on an active lane in BothIndependent mode instead of being skipped, so a WASAPI-only sender is no longer silent to a receiver that has an ASIO driver selected. Also port the per-session buffer depth-drain (stops the receive jitter buffer bloating).

Sender: add sndAudFr meter (audio frames actually sent) to localise capture vs send.

App: startup sound cue (machine-wide, Preferences); stop sending audio when no peer is reachable (issue #8). Version 3.9.1.

Server (relay): fix updater version-compare for multi-dot tags, guard the main loop against crashes, reject spoofed BYE from a mismatched endpoint.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/RemSound.Core/AppConfig.cs

@@ -68,6 +68,20 @@ public sealed class AppConfig
     /// already running quietly". Default false.</summary>
     public bool StartMinimised { get; set; }
 
+    /// <summary>If true (the default), RemSound plays the startup cue once, right after this
+    /// copy wins the single-instance takeover and before the profile loads. Machine-wide (not
+    /// per-<see cref="Profile"/>) because it fires before any profile — and its per-profile
+    /// custom-cue dictionary — has been chosen. Like the connect/disconnect cues it's audible
+    /// feedback, on by default; the user unticks "Startup sound" in Preferences to silence it.
+    /// (The usual "auto-options default off" rule is about data-persistence toggles, not cues.)</summary>
+    public bool EnableStartupCue { get; set; } = true;
+
+    /// <summary>Optional custom WAV path for the startup cue. Null = use the bundled
+    /// <c>sounds\start up.wav</c>. Machine-wide for the same reason as
+    /// <see cref="EnableStartupCue"/>: the cue plays before any profile (and the per-profile
+    /// custom-cue paths) is loaded, so it can't live on <see cref="Profile"/>.</summary>
+    public string? StartupCueCustomPath { get; set; }
+
     /// <summary>If true, RemSound writes a tab-separated diagnostic log to
     /// <c>&lt;exe&gt;\logs\</c>. Lives here (not in <see cref="Profile"/>) because logging
     /// is a debugging affordance for the installation, not a user-facing audio preference —