ci(gh-16): add an on-demand Windows installer test and move the release job self-hosted

[oliver-cieliszak-natterbox]

What

Adds a dispatch-only Windows installer test workflow, moves release.yml off GitHub-hosted ubuntu-latest onto the self-hosted Arm64 CodeBuild fleet, and fixes a Windows-only crash in setup.py that the new test found on its first run.

Why

release.yml on ubuntu-latest was a cicd-github-actions §1.3 MUST violation: a GitHub-hosted runner needs an immediately preceding # RUNNER-EXCEPTION: comment, and there was none.

The Windows workflow exists because a real defect shipped in install.ps1 that nothing in CI could catch. The version check read the last whitespace token of uv --version, which is the build target (x86_64-pc-windows-msvc)), not the version, so the "already installed, skip the download" branch was unreachable and every Windows re-run re-downloaded about 34 MB. Fixed in #15.

The setup.py crash is what the first dispatch of that new test immediately found. _ok(), _info() and _box() print a tick, an info glyph and box-drawing characters, and Python cannot encode those into a Windows pipe or redirected file, which uses a legacy code page. The installer dies with UnicodeEncodeError part-way through. An interactive console hides it, because Python uses Unicode console I/O there; anything that captures output does not, which includes CI, install.ps1 | Tee-Object, and a scheduled task writing a log.

How

The Windows job is workflow_dispatch only, with nothing on push or pull_request, because every run downloads uv and a managed CPython interpreter into fresh prefixes. Dispatch it against whichever branch you want to test. It reads the pinned version out of distro.toml at run time rather than hardcoding it, prints both interpreters' versions so the log proves what actually ran, and fails if the second install re-downloads.

PowerShell 7 invokes install.ps1 directly. Windows PowerShell 5.1 is exercised through install.bat, which is the documented fallback for machines where script execution is blocked and is itself a powershell -ExecutionPolicy Bypass wrapper. A shell: field cannot be driven from a strategy matrix, so those are separate steps rather than a matrix dimension.

Two details in the assertion are deliberate, and both cost a failing run to learn. Write-Host output goes to the information stream, so the installer's messages are only visible with 6>&1 alongside 2>&1; without it the check cannot see the installer at all. And the re-download check reads the output text rather than uv.exe's timestamp, because install.ps1 copies the binary out of the archive with Copy-Item, which preserves the archive's own timestamp, so a re-download of the same version leaves the write time unchanged.

release.yml moves to the Arm64 fleet because the runner image is almalinux:10 and installs the zip CLI and gh 2.102.0, which is everything this job uses, and redmatter/nbinternal-skills already creates releases with attached assets from the same fleet. It keeps the zip CLI rather than Python's zipfile, because zip preserves the executable bit on install.sh and zipfile would not.

setup.py now reconfigures stdout and stderr to UTF-8 with a replace fallback before printing anything. UTF-8 keeps the glyphs readable in modern logs, and the fallback means an unprintable character can never abort an install again.

Test Steps

1. gh workflow run test-windows-installer.yml --ref bugfix/gh-16-ci-runner-compliance, then gh run watch.
2. On this branch the run is expected to fail, at PowerShell 7 - second install must skip rather than re-download, reporting the second run re-downloaded uv: the skip branch did not fire. That is the install.ps1 bug fix(gh-14): bump uv to 0.12.24 and fix the Windows version check #15 fixes, and catching it is the entire point of the job. Expect green once it is dispatched against a branch carrying fix(gh-14): bump uv to 0.12.24 and fix the Windows version check #15.
3. release.yml only runs on tags, so it is first exercised at the next release. After merging, tag v0.12.1 and confirm the run picks up a CodeBuild runner and publishes the ZIP.

Other Notes

• gitflow.yml is deliberately unchanged. It declares no runs-on: of its own, and the reusable workflow it calls already defaults to that same Arm64 fleet, so it is self-hosted already.
• Auditing that locally is a trap: a stale local v1 tag makes git show v1:.github/workflows/gitflow.yml report ubuntu-latest plus actions/setup-python, which is not what GitHub resolves. Use git ls-remote --tags origin v1 or git fetch --tags --force before drawing conclusions from v1.
• The zip CLI is present in the fleet image but is not yet exercised by any workflow in the org. A failure would occur before gh release create, so the job fails closed rather than publishing a broken release.
• release.yml has no job-level permissions: block. §3.2 reads as a SHOULD gap; it is pre-existing, so it is left alone here rather than widening this change.
• The setup.py fix rides in this PR rather than its own, on the owner's call, so this branch carries one CI change and one installer fix.
• The Windows job is dispatchable against a feature branch before it reaches the default branch, so it is usable on PRs straight away.

Closes #16

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

🛠️ Fix a finding or handle a false positive

• Auto-Fix: Run /orca-pr-scan-fix to automatically remediate or suppress PR findings.
• In-Code: Suppress via inline comments or exception files (see CLI References).
• In Orca: Dismiss or snooze directly via Changing Alert Statuses.