fix: harden notification sound playback against hangs and dropped sounds

[GraysonCAdams]

TopNotify's sound queue used a bare BlockingCollection<T>.TryAdd(item), which blocks indefinitely once the queue is full rather than skipping the item as the surrounding logic assumed - a burst of notifications could deadlock playback entirely. Separately, the daemon/GUI pipe used StreamReader/StreamWriter with AutoFlush, which falls back to an uncancellable synchronous PipeStream.Write under load; confirmed via dotnet-dump thread stacks that both processes could genuinely get stuck mid-write with no way to recover short of killing the process.

Fixed both: the queue now uses TryAdd(item, TimeSpan.Zero) so a full queue drops rather than blocks, and the pipe now uses raw async ReadAsync/WriteAsync bound to a CancellationTokenSource with PipeOptions.Asynchronous on both ends (it was missing on the client, which was the actual root cause). SendCommandToDaemon now returns whether the daemon actually acknowledged, instead of assuming success.