Simplify release workflow

[danielchalmers]

Summary

Simplifies the manual release workflow for this repo's release cadence and makes the artifact action cleaner as a reusable template.

What changed

• Collapsed deploy.yml from three jobs into one sequential Release job.
• Kept CI packaging parallel, but moved artifact upload out of the composite action and into build.yml.
• Changed create-release-artifacts so it only creates release files; callers decide whether to upload them as workflow artifacts or publish them to a GitHub release.
• Made WiX setup idempotent with dotnet tool update --global wix --version 4.0.6, so the release job can package both architectures in one job.
• Removed the release workflow's cross-job artifact upload/download round trip.

Why

The release workflow is manually triggered and rare, so a sequential flow is easier to read and maintain than a parallel build/package/deploy graph. dotnet publish already builds the app for each architecture, and the release job now runs tests first, then packages x64 and arm64, then creates the release from local publish/*.zip and publish/*.msi files.

CI still validates packaging for each architecture through the existing matrix, and CI remains responsible for uploading those package outputs as workflow artifacts.

Validation

• actionlint
• git diff --check
• dotnet restore
• dotnet build -c Release --no-restore
• dotnet test -c Release --no-build --no-restore --logger trx --results-directory TestResults
• Local sequential x64 and arm64 packaging using the updated WiX setup flow

[danielchalmers]

Three strong reasons to close the change and leave the matrix-based workflow as-is:

1. The existing workflow uses GitHub Actions the intended way.
   Matrix builds are job-level in GitHub Actions, so the original package job with matrix.arch is the cleaner and more idiomatic structure. The simplified version replaces a native matrix with duplicated steps.

2. It preserves parallel packaging and clearer failures.
   With the matrix, x64 and arm64 package jobs can run independently and show separate results. If one architecture fails, it is immediately obvious which one failed. The simplified version runs them serially inside one job.

3. It keeps permissions narrower and safer.
   In the original workflow, only the deploy job needs contents: write; build and package can stay read-only. The simplified single-job version gives write permissions to the whole release job, including checkout, build, and packaging, which is a worse security posture.