Build both RIDs in CI with the publish flags that actually ship

[trsdn]

Fixes #22

CI built and published win-x64 only, while release.yml builds a matrix of win-x64 and win-arm64. An ARM64-specific break, a native dependency, a RID-specific package resolution failure, a trimming difference, was only discoverable on a v* tag push, that is during a release, when it is most expensive to fix.

build.yml now runs the same two-RID matrix. fail-fast is off so an ARM64 break does not mask the x64 result.

The second half of the issue matters more than the matrix

CI published without -p:IncludeNativeLibrariesForSelfExtract=true, which both release.yml and installer/build.ps1 pass. That flag changes what actually ends up inside the single file, so CI was signing off on an artifact that is not the one that ships. The publish step is now flag-for-flag identical to the release path, which is what makes the matrix worth anything.

The publish output was also being thrown away. It is now uploaded so PR builds are inspectable. Retention is capped at 7 days because a self-contained trimmed exe is ~185 MB per RID and this runs on every PR.

Verification

The interesting question is whether ARM64 actually builds, since nothing has ever compiled it outside a release. I ran the exact publish command locally:

dotnet publish md2loop/md2loop.csproj -c Release -r win-arm64 --self-contained true `
  -p:PublishSingleFile=true -p:PublishTrimmed=true -p:IncludeNativeLibrariesForSelfExtract=true

It succeeds. The only diagnostics are the IL2059 XamlTypeInfo and IL2104 RtfPipe trim warnings, both of which are pre-existing and appear identically on x64, so the new matrix leg will be green rather than immediately red.

Workflow file also parsed to confirm the matrix and step structure.

Note for merging

PR #41 (test project) and PR #43 (MSIX packaging) both add steps to build.yml as well. Whichever lands second will need a small rebase; the changes are in different steps so it should be mechanical.