ci(windows): cross-compile orbit.exe for Windows x86_64
Summary
Adds a Windows x86_64 build of the `orbit` CLI to the release pipeline. The new job cross-compiles from a Linux runner using llvm-mingw (UCRT, libc++) with Rust's `x86_64-pc-windows-gnullvm` target. DuckDB is statically linked via the existing `duckdb-client/bundled` feature, matching the Linux/macOS shape.
Output: `orbit-local-windows-x86_64.zip` (~117 MB), self-contained — only Windows system DLLs are imported, so it runs on a stock Windows 10+ machine with nothing to install alongside.
What changed
- New CI job `local-cli-build-windows-amd64` on `saas-linux-xlarge-amd64`, ~4 minutes.
- `scripts/build-local-cli.sh` learned the `windows` platform and the gnullvm target.
- `scripts/upload-local-cli-release.sh` ships the new zip alongside the existing tarballs on `vX.Y.Z` tag pipelines.
How the static linkage works
llvm-mingw distributes libc++ and libunwind as both `.a` (static) and `.dll` + `.dll.a` (shared + import lib). With Rust's gnullvm target spec auto-adding `-lc++` and `-lunwind`, the linker would otherwise pull both forms and emit duplicate-symbol errors. The job's `before_script` deletes the four import-lib/DLL files so only the static archives resolve, and `-static-libstdc++ -static-libgcc` in `RUSTFLAGS` directs clang++ to use them. Removing `-pc-windows-gnu` (Debian's mingw-w64) was necessary because that target ships libstdc++ only as a DLL, defeating any `-static-libstdc++` request.
Related
Test plan
- Pipeline green on MR, job `local-cli-build-windows-amd64` succeeds.
- Manual smoke: `orbit.exe --version` runs on Windows with no DLLs alongside.
- Tag pipeline (will validate on the next release).