ci: use extension-ci-tools v1.4.5 so windows_amd64 builds with MSVC

[asubbarao]

Why

windows_amd64 has been red on main since 2026-07-20 (run 29782822867), and on every PR since. No tests run: make test_release exits Error 127 on ./build/release/"/test/unittest" ""test/"*".

The cause is the runner image, not the tests. windows-latest is now windows-2025-vs2026 (line 16 of the job log). extension-ci-tools v1.4.4 only calls the VS 2022 vcvars64.bat, which doesn't exist on that image (The system cannot find the path specified.), and it leaves CC/CXX empty. So CMake picks MinGW from PATH:

-- The C compiler identification is GNU 15.2.0
-- Check for working CXX compiler: C:/mingw64/bin/c++.exe

The GCC-built unittest.exe then fails to start under Git Bash, which reports that as a silent 127. It also means windows_amd64 artifacts built this way are GCC-built rather than MSVC-built.

extension-ci-tools v1.4.5 (duckdb/extension-ci-tools#369) tries the VS 18 vcvars first and sets CC/CXX to cl. git diff v1.4.4 v1.4.5 touches only _extension_distribution.yml; the Makefiles are identical.

Change

Pin _extension_distribution.yml and ci_tools_version to v1.4.5. duckdb_version stays v1.4.4.

Evidence

• Failing: PR parse_functions: find functions inside FROM-clause subqueries, joins and table-function arguments #17 run 36061095091, job 107913882144 (above), and main run 29782822867, job 88491492661 (same failure).
• Control: teaguesterling/duckdb_read_lines job 107820187154 ran on the same image the same week, with a byte-identical test command, built with MSVC 19.51 from Microsoft Visual Studio\18, and reports All tests passed.
• This PR's own CI run is the confirmation: the windows_amd64 job should report an MSVC compiler and run the tests.

🤖 Generated with Claude Code

[asubbarao]

Pushed a second commit. The v1.4.5 bump worked exactly as intended — CI now finds MSVC 19.51 instead of silently falling back to MinGW — but that uncovered a real, separate bug: DuckDB's vendored fmt needs C++17 (`inline variables require at least '/std:c++17'`, format.h:326), and `duckdb/CMakeLists.txt` pins `CMAKE_CXX_STANDARD 11` as an unforced cache default. MSVC has no `/std:c++11`, so under real MSVC that resolves to its implicit default dialect, which doesn't enable inline variables.

Fix: this repo's own Makefile now passes `-DCMAKE_CXX_STANDARD=17` on the cmake command line, scoped to `windows_amd64` only (verified with `make -n`: the flag appears in the real cmake invocation for windows_amd64 and is absent for windows_amd64_mingw/macOS). `-D` on the command line wins over duckdb's unforced `set(... CACHE ...)`, and neither `fmt`'s own CMakeLists.txt nor duckdb's sets a per-target override that would defeat it — checked both.

I can't compile under MSVC on this machine, so I verified everything that's checkable without a Windows toolchain (the generated cmake command, the CMake cache-precedence rule, the absence of a target-level override) but the actual compile is only provable by this PR's own CI run.

🤖 Generated with Claude Code