feat(release): macOS Intel builds, a native Windows installer, and an asset gate

[filipeforattini]

Windows had no installer at all: install.sh only runs under git-bash and, even there, just dropped the .exe in ~/Downloads for the user to click. macOS Intel was not being built. And nothing verified that the assets the installers resolve by name actually made it onto the release.

Architectures

Adds the x86_64-apple-darwin leg, cross-compiled on the macos-14 arm runner — the reason it was dropped originally is that GitHub's Intel macos-13 runners are scarce enough that the leg sat queued forever. The Apple SDK is universal, so --target covers Rust; the other two components have to be pointed at x86_64 explicitly:

• red sidecar → REDDB_TARGET → red-macos-x86_64
• Bun engine → new ENGINE_TARGET → --target=bun-darwin-x64

Verified locally on Linux: both come out Mach-O 64-bit x86_64 under the names Tauri expects in externalBin.

No Windows arm64 leg — this is blocked upstream, not an omission: RedDB publishes no red-windows-aarch64.exe sidecar to embed (checked v1.23.1 and v1.23.2). arm64 hosts install the x86_64 build and run it under emulation, which both installers detect and report.

Windows installer

install.ps1 + uninstall.ps1, at parity with install.sh: resolves the tag from the /releases/latest redirect, verifies sha256 against checksums.txt, runs the NSIS setup silently (per-user, no admin prompt), then wires the user PATH and an rr.cmd forwarder.

Tested for real in a mcr.microsoft.com/powershell container against the live v0.64.4 release, which caught a bug that would have shipped:

Invoke-WebRequest(...).Content returns a byte[], not a string, when GitHub serves the asset as application/octet-stream. The split matched no lines, so every asset "had no checksum" and verification was silently skipped — on real Windows too.

Fixed by downloading checksums.txt to disk and reading it with Get-Content -Raw. Now passes with a negative control (tampered file → mismatch detected).

The installed binary and version are discovered from the uninstall registry hives rather than hardcoded, since Tauri has changed both the key name and the exe name across versions.

Asset gate

Following dit#44. Staging is best-effort per file (a missing bundle only emits ::warning::), so a leg that builds nothing still yields a "successful" release missing the exact .exe install.ps1 asks for. New verify-assets job between build and checksums fails when a required asset is absent or empty.

Replayed against v0.64.4's real asset list it passes (warning on the not-yet-built mac Intel dmg); drop the Windows setup from that set and it fails; upload it empty and it fails.

The new macOS Intel leg is marked optional + continue-on-error because every downstream job needs: build — a first-run failure of a cross-compile that has never run in CI would otherwise skip checksums.txt and the release notes for every platform. Promote it to required once it ships green.

Verification

• pnpm run check clean
• Engine cross-compile → Mach-O 64-bit x86_64; Windows target → correct .exe suffix
• reddb:preflight passes for all five shipping targets against v1.23.1
• Both .ps1 files parse under pwsh 7.4; live download + checksum verify + negative control pass
• Gate logic exercised across 4 cases (real asset set, missing required, empty required, full house)

Caveat: the macOS Intel cargo build --target x86_64-apple-darwin has never run in CI. The sidecar chain is validated locally, but the Rust/WebKit build on the arm runner only proves itself on the first real Release — which is exactly why that leg is optional for now.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}