ci: use native ARM64 runners and add merge commit release notes

[Copilot]

Upgrades CI workflows to leverage native windows-11-arm runners and enables custom release notes via merge commit body.

Release Workflow (release.yml)

• Extracts merge commit body and prepends to release notes before categorized commit history
• Allows writing custom release commentary directly in merge commit message

$mergeCommitBody = git log -1 --pretty=format:"%b" HEAD
if (-not [string]::IsNullOrWhiteSpace($mergeCommitBody)) {
  $releaseNotes += "$mergeCommitBody`n`n---`n`n"
}

Build Workflow (build.yml)

• Replaces single job with matrix strategy across x64, x86, arm64
• x64: native compilation on windows-latest
• x86: cross-compile via x64_x86 on windows-latest, tests run under WoW64
• arm64: native compilation on windows-11-arm (eliminates cross-compilation)
• Robust vswhere.exe detection for both legacy and native VS installation paths
• Each architecture compiled and tested in single matrix job

Architecture-specific binaries are produced (win-witr-x64.exe, etc.) then copied to generic name for test execution.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ci upgrade</issue_title>
<issue_description>we don't have to cross compile arm anymore, github actions has windows-11-arm labels for runners.

the upgrades I want:

• in release.yml, I want the actual merge commit extended description to be added to the top of the release as a sorta personal "release notes" so i can write it myself, and then the commit history is after that.
• in build.yml, i want it to be a matrix that compiles all arch versions, then another matrix that tests them (it can be the same matrix job actually). for x86 there isn't a specific runner for that but we can just run it in x64 either way since they're compatible (WoW64). the only one that's really that different is arm64
• in build.yml, perhaps we can take the output of the batch tests and post them in a comment ONLY when the build runs in a pull request. that way, i can see a comment like:

Tests Completed

x/x tests passed

Test 1 (name of bat file)

``` output here ```

and so on</issue_description>

<agent_instructions>actually you don't need to do the comment part if you're gonna screw it up because you messed it up in PR #62</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes ci upgrade #61

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Summary by CodeRabbit

• Chores
  • Added multi-architecture build support for Windows (x64, x86, arm64).
  • Improved release notes generation to include merge commit information.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• ✅ Full review completed - (🔄 Check again to review again)

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[supervoidcoder]

lgtm

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/release.yml (1)

300-345: ⚠️ Potential issue | 🟠 Major

Release build for arm64 still uses cross-compilation, inconsistent with build.yml.

The PR objective states to "use native windows-11-arm runners" and build.yml correctly uses windows-11-arm for arm64 with native vcvars_arch: arm64. However, this release workflow still runs all architectures on windows-latest and cross-compiles arm64 using x64_arm64.

Consider aligning with the build.yml matrix approach:

♻️ Proposed fix to use native runners in release workflow

   build:
     name: Build matrix for multiple Windows architectures
     needs: prepare
     if: needs.prepare.outputs.should_release == 'true'
-    runs-on: windows-latest
     strategy:
       matrix:
-        arch: [x64, x86, arm64]
+        include:
+          - arch: x64
+            runner: windows-latest
+            vcvars_arch: x64
+          - arch: x86
+            runner: windows-latest
+            vcvars_arch: x64_x86
+          - arch: arm64
+            runner: windows-11-arm
+            vcvars_arch: arm64
+    runs-on: ${{ matrix.runner }}
         
     steps:
       - uses: actions/checkout@v4

       - name: Compile for ${{ matrix.arch }}
         shell: cmd
         run: |
-          `@echo` off
-          REM Find vcvarsall.bat dynamically
-          for /f "usebackq tokens=*" %%i in (`"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath`) do (
+          REM Find vcvarsall.bat dynamically - check both possible vswhere.exe locations
+          set "VSWHERE_LEGACY=C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
+          set "VSWHERE_NATIVE=C:\Program Files\Microsoft Visual Studio\Installer\vswhere.exe"
+          
+          if exist "%VSWHERE_LEGACY%" (
+            set "VSWHERE_PATH=%VSWHERE_LEGACY%"
+          ) else if exist "%VSWHERE_NATIVE%" (
+            set "VSWHERE_PATH=%VSWHERE_NATIVE%"
+          ) else (
+            echo Error: vswhere.exe not found in either location.
+            exit /b 1
+          )
+          
+          for /f "usebackq tokens=*" %%i in (`"%VSWHERE_PATH%" -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath`) do (
             set "VS_PATH=%%i"
           )
           
           if not exist "%VS_PATH%\VC\Auxiliary\Build\vcvarsall.bat" (
             echo Error: vcvarsall.bat not found.
             exit /b 1
           )

-          REM Map architecture for cross-compilation (host_target)
-          REM GitHub Actions windows-latest runners are x64, so we need x64_<target> for cross-compilation
-          set "TARGET_ARCH=${{ matrix.arch }}"
-          set "VCVARS_ARCH=%TARGET_ARCH%"
-          if "%TARGET_ARCH%"=="x86" set "VCVARS_ARCH=x64_x86"
-          if "%TARGET_ARCH%"=="arm64" set "VCVARS_ARCH=x64_arm64"

           REM Initialize environment for the target architecture
-          call "%VS_PATH%\VC\Auxiliary\Build\vcvarsall.bat" %VCVARS_ARCH%
+          call "%VS_PATH%\VC\Auxiliary\Build\vcvarsall.bat" ${{ matrix.vcvars_arch }}

🤖 Fix all issues with AI agents

In @.github/workflows/build.yml:
- Around line 6-19: The workflow's build matrix in the build-and-test job
includes a runner value "windows-11-arm" for ARM64 which is only available to
public repos; verify repository visibility and if this repo is private update
the matrix to use an appropriate paid/large ARM64 runner or a self-hosted ARM64
runner instead of "windows-11-arm" (or conditionally set the matrix entry based
on visibility), and ensure vcvars_arch stays correct for the chosen runner
(e.g., keep the entry with vcvars_arch: arm64 but swap runner to the paid ARM64
runner or self-hosted label).

🧹 Nitpick comments (2)

.github/workflows/release.yml (1)

315-315: Inconsistent use of @echo off between workflows.

This file uses @echo off at line 315, but build.yml removed it per commit message. Consider removing for consistency and better debugging output in CI logs.

🔧 Proposed fix

         run: |
-          `@echo` off
           REM Find vcvarsall.bat dynamically

.github/workflows/build.yml (1)

53-54: Minor compiler flag inconsistency with release.yml.

This workflow uses /O2 /GL while release.yml uses /O2 /Ot /GL. The /Ot flag favors fast code over small code. Consider aligning the flags between workflows for consistent build behavior, or intentionally differentiating (e.g., faster builds for PR checks).