fix: pin Windows CI jobs to windows-2022 until VS 2026 support lands

[BenJule]

Summary

Pin the Windows CI jobs to windows-2022 so the build stops failing on every PR.

windows-latest now resolves to the windows-2025-vs2026 image, which ships Visual Studio 2026 (v18) only - no VS 2022. So the hardcoded cmake -G "Visual Studio 17 2022" fails at configure time:

Image: windows-2025-vs2026
CMake Error: Generator Visual Studio 17 2022 could not find any instance of Visual Studio.

windows-2022 still provides Visual Studio Enterprise 2022 (17.14), matching the Visual Studio 17 2022 generator and the ..._vs2022.zip deps cache built by build_deps.yml. This unblocks the Windows deps + slicer build for all current PRs.

This is a stop-gap: @MackBambu is adding proper Visual Studio 2026 support upstream, which will supersede this pin (the ..._vs2022.zip deps cache will need a matching VS 2026 rebuild at that point).

Scope

Narrowed to the Windows-runner pin only. The unrelated CI fixes that were originally bundled here (ubuntu-20.04 removal, podman buildx, main→master branch refs, setup-msbuild v3, winget-releaser pin, brew dedup) are split out to #11277 so they can land independently of the VS work.

Test plan

• Like-for-like runner pin, no build logic changed.
• My fork already builds the Windows target green on windows-2022 (VS 2022 17.14).

[BenJule]

Apologies — this PR was closed by mistake on 2026-06-07, and that was an error on my side, not a deliberate decision to withdraw the change.

It happened as an unintended side effect of a branch cleanup in my fork: deleting the head branch automatically closed this PR. The contribution still stands. I have restored the branch and reopened the PR. Sorry for the noise and any confusion this caused.

[BenJule]

Updated to fix the Windows build, which is currently broken on every PR.

This PR originally pinned the Windows runner to windows-2025, but windows-latest / windows-2025 now resolves to the windows-2025-vs2026 image, which ships Visual Studio 2026 (v18) only, no VS 2022. So cmake -G "Visual Studio 17 2022" fails at configure time:

Image: windows-2025-vs2026
vswhere -> C:\Program Files\Microsoft Visual Studio\18\Enterprise
CMake Error at CMakeLists.txt:18 (project):
  Generator Visual Studio 17 2022 could not find any instance of Visual Studio.

(seen today e.g. on https://github.com/bambulab/BambuStudio/actions/runs/27950300224)

Changed the pin to windows-2022, which still provides Visual Studio Enterprise 2022 (17.14), matching the Visual Studio 17 2022 generator and the …_vs2022.zip deps cache built by build_deps.yml. This unblocks the Windows deps + slicer build for all current PRs.

[BenJule]

@lanewei120 when you have a moment, this is currently blocking the Windows build on every open PR.

windows-latest now resolves to the windows-2025-vs2026 image (Visual Studio 2026 / v18 only), so the hardcoded cmake -G "Visual Studio 17 2022" fails with "could not find any instance of Visual Studio". This PR pins the Windows jobs to windows-2022 (VS 2022 17.14), which matches the …_vs2022.zip deps cache.

The macOS half of the same CI breakage (Assimp's bundled zlib vs the macOS 15.5 SDK) is fixed separately in #11051, which is green and ready. Merging both would get CI green across all current PRs again. Thanks!

[BenJule]

For reference: my fork's CI already uses windows-2022, and it builds the Windows target green, e.g. the Windows / windows-2022 (x64) → Build BambuStudio job here: https://github.com/BenJule/BambuStudio/actions/runs/27594436885 ✓

So pinning upstream to windows-2022 (this PR) should restore green Windows builds, while windows-latest keeps failing because it now resolves to the VS 2026 image.

[MackBambu]

I’m working on adding support for Visual Studio 2026 and fixing the related issues.

[BenJule]

Thanks Mack, glad VS 2026 support is being picked up properly - that's the right long-term fix and better than the stop-gap here.

Just so the context doesn't get lost: this PR pins the Windows jobs back to windows-2022 purely as an immediate unblock. windows-latest started resolving to the windows-2025-vs2026 image (VS 2026 / v18 only), so the hardcoded cmake -G "Visual Studio 17 2022" fails at configure on every open PR right now, and windows-2022 was the like-for-like match for the existing …_vs2022.zip deps cache. Once your VS 2026 work lands I'm happy to drop the Windows part of this PR entirely.

One thing worth having on your radar for the switch: build_deps.yml currently produces a …_vs2022.zip cache, so the dependencies will need a matching VS 2026 rebuild - otherwise the slicer build ends up linking against VS2022-built deps.

The rest of this PR is unrelated to the toolchain and fixes CI that's broken on its own: ubuntu-20.04 was removed so build_ubuntu fails immediately, podman buildx has no buildx subcommand, a couple of push triggers/conditions still point at main instead of master, plus a setup-msbuild v3 bump and a winget-releaser pin. I'm happy to carve those out into a separate PR so they can go in now without touching anything Windows/VS-related - just say the word.

[BenJule]

Narrowed this PR down to just the windows-2022 pin so it doesn't overlap with the VS 2026 work. The unrelated CI fixes that were bundled in here (ubuntu-20.04 removal, podman buildx, main->master refs, setup-msbuild v3, winget-releaser pin, brew dedup) are now in #11277 and can go in independently.