perf(installer): shrink MSI size

[hoobio]

Summary

Drops the Earmark MSI from 91 MB to 68 MB (-26%) and the uncompressed self-contained publish output from 310 MB to 233 MB (-25%) by removing two transitively-bundled payloads that Earmark does not use.

Size before / after

Metric	Before	After	Delta
MSI (compressed)	91 MB	68 MB	-23 MB (-26%)
Publish dir (uncompressed)	310 MB	233 MB	-77 MB (-25%)
Files in publish dir	639	554	-85

Changes

• NAudio metapackage swapped for NAudio.Wasapi. The metapackage transitively pulls NAudio.WinForms, which framework-references Microsoft.WindowsDesktop.App.WindowsForms and brought ~24 MB of WinForms binaries (System.Windows.Forms.dll, .Design, .Primitives, .Private.Windows.Core, System.Drawing.Common, System.Configuration.ConfigurationManager) into self-contained publish output. Earmark.Audio only uses NAudio.CoreAudioApi (which lives in NAudio.Wasapi), so the swap is API-compatible.
• Microsoft.WindowsAppSDK.ML payload pruned (~41 MB raw / ~17 MB compressed). WindowsAppSDK 1.8 transitively pulls Microsoft.WindowsAppSDK.ML 1.8.2192, which copies onnxruntime.dll, DirectML.dll, Microsoft.Windows.AI.MachineLearning.dll, plus the Microsoft.ML.OnnxRuntime.dll managed wrapper into self-contained publish output. Earmark does not use Windows ML. There is no supported opt-out yet (microsoft/WindowsAppSDK#5969); two new MSBuild targets in src/Earmark.App/Earmark.App.csproj strip the ML files from ReferenceCopyLocalPaths/None and from ResolvedFileToPublish via a filename regex. If WindowsAppSDK later wires a runtime probe to these files this exclusion will need to come back out, but at runtime today the WindowsAppRuntime bootstrap does not LoadLibrary onnxruntime/DirectML unless Windows ML APIs are actually invoked.
• JSON serialization moved to source-generated JsonSerializerContext for AppSettings and List<RoutingRule>. Trim/AOT-friendly and slightly faster, even though full trimming is currently disabled.

Deliberately not done

• PublishTrimmed=true. Tried it. .NET 10's trimmer hard-strips System.StubHelpers.InterfaceMarshaler (the classic-COM marshalling stub) when classic COM is reachable, even with BuiltInComInteropSupport=true and an explicit TrimmerRootDescriptor. The trimmer prints IL2026: Built-in COM support is not trim compatible and the runtime then throws TypeLoadException on the first MMDeviceEnumerator construction. Earmark's Core Audio path goes through NAudio.CoreAudioApi (classic [InterfaceType(InterfaceIsIUnknown)]) plus our own IPolicyConfigVista and IAudioPolicyConfigFactory interop, so trimming would require migrating to ComWrappers source-generators. Left as future work and called out inline in Earmark.App.csproj.
• Removing NAudio entirely. The remaining NAudio.Core + NAudio.Wasapi together are ~120 KB; replacing them with hand-rolled COM interop (similar to what we already do for IPolicyConfigVista) is roughly five COM interface declarations plus IID/HResult plumbing, for negligible MSI savings. Worth doing only as a precondition for the trimming work above.

Testing

Validated end-to-end on this Windows 11 host:

• dotnet publish src/Earmark.App/Earmark.App.csproj -c Release -p:Platform=x64 -p:RuntimeIdentifier=win-x64 -p:WindowsPackageType=None -p:WindowsAppSDKSelfContained=true -p:SelfContained=true -o publish/x64-trimmed exit 0, no new warnings beyond the pre-existing CsWinRT/.NET WinRT projection rollups.

• wix build ... -d PayloadDir=publish/x64-trimmed -out staging/msi-x64/Earmark-1.0.0-x64.msi installer/Earmark.wxs ... exit 0.

• msiexec /i staging/msi-x64/Earmark-1.0.0-x64.msi /qn exit 0; install dir %LocalAppData%\Earmark\ populated; Earmark.App.exe launches and parks in the system tray; secondary activation surfaces the main window with title "Earmark"; rule application against running processes works (latest log shows AudioPolicyService init: ... using Win11 interface, Activated factory 'Windows.Media.Internal.AudioPolicyConfig' as Win11 layout, Applied rule Media to msedge ... -> Media (Elgato Virtual Audio)).

• Verified no forms, onnx, directml, or machinelearning files appear in the publish output after the prune.

• Manual testing on a Windows 10 (19041+) or Windows 11 host

• Tail of the latest log file under %LocalAppData%\Earmark\logs\ shows the expected Applied rule ... / Skip Set ... / Skip re-apply ... lines after the change

• Unit tests added/updated under tests/Earmark.Core.Tests

• Existing tests pass (dotnet test -p:Platform=x64) - no test changes; the existing Core.Tests scaffold has no rule-store tests today

Checklist

• PR title follows Conventional Commits
• Code builds without warnings (dotnet build src/Earmark.App/Earmark.App.csproj -c Debug -p:Platform=x64)
• No emoji / gitmoji in commit messages or PR title (breaks release-please)
• Architecture boundary respected: domain logic in Earmark.Core, Windows audio interop in Earmark.Audio, UI in Earmark.App
• CLAUDE.md / README / CONTRIBUTING updated if behavior, build steps, or schema changed - no behavior change requiring doc update; the inline comments in Earmark.App.csproj document the ML prune and trimming-disabled rationale