build: the exe is LlamaCasty.exe, and the publish script proves the artifact

Renames AssemblyName to LlamaCasty before the first Steam depot — Steamworks is explicit
that renaming a live exe is painful, so this had to land first, not later.

Four assembly-qualified pack URIs carried the old name, not three: MainWindow (window
icon), OverlayHost (logo), RenameRecordingDialog and KeepBroadcastDialog. Pack URIs
resolve by assembly name at runtime, so a stale one compiles, passes every test and then
silently renders nothing the first time that view opens. AssemblyIdentityTests guards
both halves — the assembly name, and no source XAML still naming the legacy assembly.
Packaging/Package.appxmanifest and package-msix.sh carry the exe name too.

scripts/publish.sh replaces the by-hand publish: single-file win-x64, ReadyToRun,
ffmpeg beside the exe, and it refuses to finish if ffmpeg, LICENSE, PRIVACY.md or
THIRD-PARTY-NOTICES.txt are missing, or if a test assembly leaked in.

That last guard exists because the first publish was wrong in a way no test could see:
PublishSingleFile + IncludeNativeLibrariesForSelfExtract bundled the libav*.dll family
into the exe — a 9-file output with no ffmpeg folder and a 182 MB binary, so the locator
would have found nothing at runtime. ExcludeFromSingleFile="true" on the content keeps
the folder a folder. Diffing against a control publish without the single-file flags
found it; guessing at item globs wasted two attempts first (recorded in MyMistakes.md).

Measured: 127 MB exe + 129 MB ffmpeg = 257 MB depot. Tests: AssemblyIdentity,
StorePackaging, BuildStamp, BundledFonts all pass; app builds with 0 warnings.

ytLive.csproj

@@ -8,7 +8,10 @@
     <UseWPF>true</UseWPF>
     <EnableWindowsTargeting>true</EnableWindowsTargeting>
     <ApplicationIcon>Assets\llamacasty-icon.ico</ApplicationIcon>
-    <AssemblyName>ytLive</AssemblyName>
+    <!-- The shipped exe is LlamaCasty.exe (renamed 2026-11-01, before the first Steam depot so
+         the store never sees the legacy name). RootNamespace stays `ytLive` — the C# namespaces
+         are not user-visible and renaming them would churn every file for no benefit. -->
+    <AssemblyName>LlamaCasty</AssemblyName>
     <RootNamespace>ytLive</RootNamespace>
     <!-- 64-bit Windows only (creator ruling 2026-10-09). The bundled ffmpeg is the win64 build
          and ONNX Runtime ships no win-x86 native, so a 32-bit process could never stream; a
@@ -116,7 +119,19 @@
        from a pinned URL, verifying SHA-256 first. CopyToPublishDirectory=Always is the
        one that matters for the MSIX package. -->
   <ItemGroup>
-    <None Include="ffmpeg\**" CopyToOutputDirectory="PreserveNewest" CopyToPublishDirectory="Always" />
+    <!-- `Remove` first: the SDK's default None glob already matched ffmpeg\**, so an Include
+         without removing it produced DUPLICATE items — one carrying the copy metadata and one
+         with none. Harmless until PublishSingleFile + IncludeNativeLibrariesForSelfExtract came
+         along, where the bundler collapses the duplicate and the folder silently stops being
+         published (found 2026-11-01: a 9-file publish with no ffmpeg in it). -->
+    <!-- ⛔ ExcludeFromSingleFile is load-bearing. With PublishSingleFile +
+         IncludeNativeLibrariesForSelfExtract the bundler treats the libav*.dll family as native
+         libs and swallows them INTO the exe — a 182 MB exe with no ffmpeg\ folder beside it, so
+         the locator finds nothing and every stream fails at runtime. The metadata keeps the
+         folder a folder. (Found 2026-11-01 by diffing the publish output against a control
+         publish without the single-file flags.) -->
+    <None Remove="ffmpeg\**" />
+    <None Include="ffmpeg\**" CopyToOutputDirectory="PreserveNewest" CopyToPublishDirectory="Always" ExcludeFromSingleFile="true" />
   </ItemGroup>
 
   <Target Name="GuardBundledFfmpeg" BeforeTargets="CoreCompile">