Windows: build in rootfs-images v8.10 (GCC 15.2), add scheduled optimized builds

[maleadt]

This moves Julia's Windows builds to rootfs-images v8.10 (GCC 15.2) and adds daily optimized Windows x86-64 nightlies, which need that image. Both are in one PR so a single CI run covers them.

Windows builds in rootfs-images v8.10

The v8.10 package-windows-{x86_64,i686} images compile with GCC 15.2 and binutils 2.45.1 from GCCToolchain_jll (JuliaCI/rootfs-images#294, JuliaPackaging/Yggdrasil#14916). v8.5 used MSYS2's GCC 16.1 on x86_64 and mingw-builds GCC 12.2 on i686. The new toolchain is the one CompilerSupportLibraries_jll is built with, so the headers and import libraries now match the runtime DLLs Julia ships. This is the Windows counterpart of #638.

v8.10 differs from v8.9 only in carrying MSYS2's -mno-align-vector-insn patch, enabled by default (JuliaCI/rootfs-images#295). Without it, the coverage job's -march=native build crashed on its first run of julia.exe in v8.9, on an aligned AVX store to a stack slot GCC cannot align on 64-bit Windows (julia-buildkite-ci build 182).

Every Windows DOCKER_TAG pin moves from v8.5 to v8.10: the per-commit build and upload rows, the no-GPL rows and the Windows coverage job.

i686 needs JuliaLang/julia#63350 (merged). With the new MinGW headers, isfinite becomes an out-of-line call, and without that PR's -mfpmath=sse the rest of julia_fma stays in x87 precision, so Base.fma_float returned NaN.

Optimized Windows nightlies

The new x86_64-w64-mingw32opt build uses Julia's contrib/optimized flow (JuliaLang/julia#63214) with PGO and ThinLTO, without BOLT. Artifacts are published under julialangnightlies/bin/windowsopt/, going through the same installer, zip and signing steps as the regular Windows nightlies. The winnt aliases stay limited to the regular build. Registering a juliaup channel is separate work.

The optimized build is why the image had to change. It compiles LLVM itself, and with v8.5's GCC 16 headers LLVM needs libstdc++ symbols that CSL's DLLs lack (undefined symbol: std::__get_once_callable(), julia-buildkite-ci build 170). In v8.10 it needs no Julia change, because clang finds the toolchain through PATH.

Windows-specific changes:

• The Docker plugin only passes listed variables into the container, so JULIA_CI_BUILD_MODE is added to that list.
• contrib/download_cmake.sh has no Windows binaries, so the build uses the CMake from the image.
• The Windows checks in build_envs.sh, test_julia.sh and upload_julia.sh now match windows* instead of exact names. This gives the optimized build its .exe suffix and the Windows packaging, and also applies the executable and test handling to the no-GPL build.

The build has a 600-minute timeout, as it builds LLVM and Julia twice. It took about 100 minutes, including packaging, in a Windows Server 2022 VM, so the CI duration is still an estimate. Tests keep the regular 225-minute timeout. Only x86-64 is enabled, because the 32-bit toolchain runs out of address space during ThinLTO links.

Validation

Validated in a Windows Server 2022 VM, using images built from #294's Dockerfiles and build_julia.sh with a stubbed Buildkite agent. Each build passed an import audit: every PE import resolves against CSL's DLLs, and the shipped DLLs are CSL's. Each also passed the core, numbers, strings, math, misc, threads, ccall and exceptions tests:

• x86_64 plain build (Julia master).
• x86_64 optimized build (unchanged Julia master).
• i686 plain build (Julia master + build: use SSE math on 32-bit x86 also when the tarball name is given JuliaLang/julia#63350).

Those builds used MAKE_FLAGS=VERBOSE=1, so this CI run is the first test of the -Werror flags with GCC 15.2. S3 staging, signing and publishing were not exercised. The renderer tests cover the new jobs, the mode forwarding, the timeouts and the publish gating.

[maleadt]

All Windows jobs are passing here.