Windows: play notification sounds in-process instead of spawning powershell.exe per event

[ynjmxn]

Summary

On Windows, every Herdr notification sound starts a new powershell.exe
process. PowerShell loads WPF MediaPlayer, plays the bundled audio file,
and exits after playback completes.

Playback works correctly, and the child process does not remain indefinitely.
However, spawning a PowerShell process for every Done/Request notification
causes avoidable process churn and creates noise in process monitors, audit
logs, antivirus software, and EDR tools.

Environment

• Herdr: 0.8.2
• OS: Windows 11 25H2, build 26200.9278
• Sound configuration:

[ui.sound]
enabled = true

Steps to reproduce

1. Start Herdr on Windows with notification sounds enabled.
2. Trigger an event that plays the Done or Request sound.
3. Observe the process list or Windows PowerShell event log.
4. A new powershell.exe process is created for that notification.
5. The process exits after the audio finishes, usually within a few seconds.
6. Trigger another notification and another PowerShell process is created.

Observed behavior

In one local observation period, 25 notification-sound PowerShell processes
were created over two days. Most existed for approximately 1.3 to 2.7
seconds.

There was no persistent-process leak. The concern is the repeated creation
of a command interpreter for each short notification sound.

The current Windows implementation in src/sound.rs follows this path:

Herdr
  -> powershell.exe
     -> WPF MediaPlayer
        -> temporary herdr-sound-*.mp3

Expected behavior

Herdr should preferably play notification sounds through an in-process
Windows audio API, without starting a command interpreter for each event.

Possible implementation

A relatively small Windows-specific implementation could:

1. Store the built-in notification sounds as WAV resources.
2. Play them in-process with PlaySoundW from winmm.dll.
3. Use asynchronous flags such as SND_ASYNC | SND_MEMORY | SND_NODEFAULT.
4. Keep the audio buffer alive until asynchronous playback is complete.
5. Define how a new notification behaves when another sound is still playing.

This would avoid both powershell.exe and the temporary MP3 file.

If retaining MP3 assets is important, Windows Media Foundation or another
in-process Windows audio API could be considered, although that would require
more implementation work.

Related work

• [Windows] No toast popup for herdr/terminal/system delivery; sound fails with player exit code 1 #1330 reported Windows notification and sound playback failures.
• fix(windows): restore system notifications and sound playback #2019 fixed playback and ensured PowerShell players exit promptly, but retained
  the per-notification PowerShell architecture.
• feat: emit terminal bell on agent notifications #626 proposed emitting a terminal bell, but it was not merged and would not
  remove the existing sound process unless terminal bell were offered as an
  alternative backend.

Scope

This request does not claim that the current implementation leaks processes
or fails to play audio. It concerns Windows integration, process overhead, and
audit/EDR noise caused by starting powershell.exe for every notification.

Would the maintainers accept an in-process Windows sound backend, potentially
using bundled WAV files and PlaySoundW?