feat: add Windows build and resolve frontend version from GH variable

[butschster]

What

1. Adds a Windows amd64 release artifact (buggregator-windows-amd64.exe).
2. Resolves FRONTEND_VERSION from the workflow_dispatch input → repo vars.FRONTEND_VERSION → hardcoded fallback, so the embedded UI version no longer has to be edited inside the workflow file.
3. Threads FRONTEND_VERSION into the Docker build-args so the published image picks up the same version.
4. CI now cross-compiles windows/amd64 so build-constraint regressions get caught on PRs.

Why

• The repo already has a Variable FRONTEND_VERSION = 1.32.1 but the workflow ignored it (hardcoded 1.32.0), so bumping the UI required two commits. Pulling from vars.FRONTEND_VERSION (with a literal fallback for forks) makes the Variable authoritative and lets the maintainer also override per-run via workflow_dispatch input.
• The previous workflow had a TODO note explaining Windows was disabled because box.phar can't detect Composer on Windows CI (box#1097) and static-php-cli has no micro.sfx for Windows. The conclusion was correct — we can't bundle the PHP runtime — but it skipped what's still possible: cross-compiling the Go server itself, with VarDumper turned off at runtime.

How

Windows build

• cmd/buggregator/main.go — runtime.GOOS == "windows" skips StartPHP() (the call that would try to exec the placeholder binary and exit(1)). Module.TCPServers() already returns nil when the parser isn't running, so :9912 stays unbound. Every other module ingests normally.
• release.yml — new build-windows job. Same shape as the unix matrix minus the static-php / micro.sfx step; writes a placeholder byte stub so //go:embed bin/vardumper-parser-windows-amd64.exe resolves, then CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build. release job now depends on build-windows too.
• ci.yml — adds a windows/amd64 cross-compile step so build constraint mistakes fail in PR rather than the next release.

Frontend version resolution

• release.yml — top-level env.FRONTEND_VERSION is now inputs.frontend_version || vars.FRONTEND_VERSION || '1.32.0'. The fallback string only matters on forks that don't set the Variable.
• release.yml — workflow_dispatch input added; lets you build a one-off without bumping the Variable.
• release.yml — Docker job passes FRONTEND_VERSION through build-args so the runtime container image picks up the same value.
• Dockerfile — ARG FRONTEND_VERSION default updated to 1.32.1 to match the current repo Variable.
• release job is now gated on github.event_name == 'push' && startsWith(github.ref, 'refs/tags/'). workflow_dispatch runs produce artifacts but don't create a GitHub Release.

Why not bundle PHP on Windows

• static-php-cli distributes pre-built micro.sfx for Linux/macOS only — no Windows variant exists.
• Even building the .phar is fragile on Windows runners (box#1097).
• Shipping a Windows binary that depends on a system PHP install would be a UX regression versus the self-contained Linux/macOS binaries.

If a Windows user later needs VarDumper, the practical path is Docker Desktop or WSL — the Linux image already supports both.

Testing

• go build ./cmd/buggregator (native) and CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build locally — both produce valid binaries (PE32+ executable (console) x86-64, for MS Windows).
• go test ./... -count=1 — clean across every package.
• go vet ./... — clean.