feat: add native Windows support (server + windows/amd64 llama-cpp backend)

[LionelColaso]

Description

Adds native Windows support end to end: LocalAI now releases a windows/amd64 server binary, and the llama-cpp backend is built natively for windows/amd64 under MSYS2 UCRT64 and packaged as an OCI image tar that LocalAI installs and runs as a native process - no docker daemon or WSL required on the host.

Server side

• goreleaser: add windows (amd64/arm64) to the release targets
• Makefile: download the win64 protoc zip and rename protoc.exe to protoc, resolve code-gen plugins via --plugin instead of PATH, force SHELL=sh and name the binary local-ai.exe on Windows, ignore protoc.exe
• build-test.yaml: add a native windows-latest build gate that installs GNU make via Chocolatey, adds Git for Windows' usr/bin to PATH and builds with CGO_ENABLED=0
• pkg/downloader: close the write handle before removing or renaming a partial download so Windows file locks do not break the resume and error paths; guard the POSIX-permission and symlink tests on non-Windows
• tests: Windows guards and path fixes for core/gallery, video_internal, loader and the testcontainers database setup

Backend side

• scripts/build/llama-cpp-windows.sh: builds gRPC from source (pinned v1.59.0, with mingw-w64 fixes for c-ares, boringssl and zlib), then the three llama.cpp variants (cpu-all with GGML_CPU_ALL_VARIANTS + Vulkan, rpc, and the AVX-off fallback), bundles the mingw runtime DLLs and ships an OCI tar via local-ai util create-oci-image. Re-runnable and auto-dispatches into MSYS2 when launched from Git for Windows' bash. JOBS override supported for memory-limited hosts.
• backend/cpp/llama-cpp/run.ps1: PowerShell launcher (mirrors run.sh) that pkg/model/process.go starts on Windows
• backend/index.yaml: windows/amd64 backend entry and variants
• pkg/system/capabilities.go: windows engine preference rules so the gallery picks the native build on Windows hosts
• .github/backend-matrix.yml + backend_build_windows.yml: windows matrix entries and a reusable windows build workflow; backend.yml and backend_pr.yml wire the windows backend jobs (build on PR, publish on master)
• docs/content/getting-started/windows.md plus related page updates (GPU-acceleration, install)

Notes for Reviewers

• The Windows backend image ships three llama-cpp executables picked by the run.ps1 launcher: llama-cpp-cpu-all.exe (all ggml CPU variants, auto-detects a Vulkan device at runtime and falls back to CPU), llama-cpp-grpc.exe (gRPC-RPC build, selected when LLAMACPP_GRPC_SERVERS is set) and llama-cpp-fallback.exe (static, AVX-off fallback). The mingw runtime DLLs are bundled in the image, so no MSYS2 install is needed on the host.
• macOS is intentionally unaffected; the Darwin matrix entries are unchanged.

Signed commits

• Yes, I signed my commits.
• Documentation updated (docs/content/) for user-facing changes, or not applicable

Assisted-by: opencode:big-pickle

Closes #2368

[mudler]

why a separate main?

[LionelColaso]

Good question. Windows has no shell to run run.sh through, so the gallery's run.sh contract can't work there directly. run.exe is a small native PE that mirrors run.sh's selection logic — prefer llama-cpp-cpu-all.exe, fall back to the gRPC-RPC build when LLAMACPP_GRPC_SERVERS is set, else llama-cpp-fallback.exe — and prepends the bundled lib\ dir to PATH. pkg/model/process.go picks it up when it exists next to run.sh.

It's built at CI time by scripts/build/llama-cpp-windows.sh (CGO_ENABLED=0 go build ./backend/cpp/llama-cpp/run-windows), so changing the launcher needs no C++ toolchain. As part of this cleanup I also removed the orphaned run.cmd (see the other thread).

[mudler]

what I mean is, why not having then just a windows power shell script instead? adding a compiled binary for a launcher is really wasting space. And startup times should be nearly the same (and in any case, neglectible)

[LionelColaso]

Agreed — that's cleaner. I've replaced run.exe with run.ps1, a small PowerShell launcher that mirrors run.sh (same binary-selection and lib\ PATH logic). pkg/model/process.go now spawns powershell.exe -NoProfile -ExecutionPolicy Bypass -File run.ps1 on Windows, and the build script just copies the script into the image instead of compiling a binary — no Go build step for the launcher anymore. The compiled run-windows main is deleted.

Verified locally on Windows with a fake backend: binary selection (cpu-all / grpc / fallback), arg forwarding, lib\ PATH prepend, exit-code propagation, and a backend dir with spaces all behave correctly.

[mudler]

this is not correct, or at least is not coherent with the PR - you add a run.cmd wrapper, but then you don't call it here

[LionelColaso]

You're right — run.cmd was never invoked, and I've now removed it. The launcher this PR wires in is run.exe, a native PE built from backend/cpp/llama-cpp/run-windows, and pkg/model/process.go explicitly selects it on Windows (the branch at the lines above). The run.sh stub stays in the image purely so discovery/validation/upgrades stay uniform with the other platforms; on a Windows host the actual process spawned is run.exe.

[localai-org-maint-bot]

@mudler the Windows launcher concerns are resolved on the rebased head: the unused run.cmd is removed, the native run.exe path is now explained, and backends/llama-cpp-windows is serialized in .NOTPARALLEL. I reviewed the range-diff from the prior head; git diff --check, the launcher build, pkg/system, and all 48 backend-filter tests pass. Good from my side once the newly restarted Windows/backend CI completes.

[localai-org-maint-bot]

@mudler the requested launcher change is addressed on the rebased head: the compiled run.exe helper is gone, run.ps1 mirrors the binary selection and PATH setup, and pkg/model/process.go invokes it through Windows PowerShell. I isolated the patch from the rebase and verified git diff --check, all 48 backend-filter tests, and pkg/system; the contributor also reports native Windows launcher coverage for selection, argument forwarding, paths with spaces, and exit propagation. Good from my side; only DCO is currently reported, so the Windows/backend workflow result is still pending.