fix(audio): a DEBUG build never shares the pipe name with Release

Creator was recording on the Release build and hit "Couldn't start the audio — another copy of
LlamaCasty is already using the audio pipe" when going live on Debug. The guard did its job (no
crash), but the collision should not have been possible: the pipe name only suffixed when
`YTLIVE_INSTANCE` was set, and a Debug launched straight from the IDE has no id — so it asked for
the same `ytllive_audio` the Release build was serving.

DEBUG now always suffixes: the claimed instance id when there is one, otherwise the process id. Any
number of dev builds can run beside the Release app, and each Debug process is distinct from every
other. Release is unchanged — it resolves to the plain name, and the whole mechanism disappears in
`#if DEBUG` as before.

`TryStartAudioPipe` now logs the resolved name (`Audio pipe: …`), so the next report of this kind is
one grep instead of a code hunt.

Tests: AudioPipeInstanceTests pins that an id-less DEBUG process never resolves to the bare name;
572 green, 0 warnings.

HANDOFF.md

@@ -35,6 +35,6 @@
 - Pack URIs for bundled assets must be assembly-qualified (`/LlamaCasty;component/Assets/…`): the
   unqualified form resolves against the entry assembly, which is the test host under `dotnet test`.
 - Media sessions are keyed by **path + look** (`MainViewModel.MediaSessionKey`); never acquire by raw path.
-- **The audio pipe is one instance per machine.** DEBUG appends its id (`InstanceProfile.AudioPipeName`).
+- **The audio pipe allows ONE server per name**; DEBUG suffixes it (id, else pid), Release does not.
 - Integration tests constructing `MainWindow` must set a temporary `LayoutPathOverride` and clear it in `finally`.
 - Bundled FFmpeg stays outside the single-file exe (`ExcludeFromSingleFile="true"`).