feat(build): add Windows platform support to Makefile

[H-H1]

📝 Description

make build and make build-launcher fail on Windows (Git Bash / MSYS2) because
uname -s returns MINGW64_NT-* instead of Linux or Darwin, causing the Makefile
to fall into the else branch with no .exe suffix and no GOOS=windows set.

Changes:

• Detect Windows via findstring MINGW/MSYS/CYGWIN in uname -s, set IS_WINDOWS=yes
• Add EXE=.exe on Windows, empty on other platforms
• Set GOOS=windows GOARCH=amd64 explicitly in build and build-launcher targets
• Use cp instead of ln -sf for the alias binary on Windows (symlinks require admin privileges)
• Non-Windows platforms are unaffected

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)

🤖 AI Code Generation

• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)

🔗 Related Issue

Closes #2050

📚 Technical Context (Skip for Docs)

• Reference URL: N/A
• Reasoning: Git Bash reports MINGW64_NT-10.0-19045 for uname -s. The original
  Makefile only handled Linux and Darwin, so Windows builds produced binaries without
  .exe suffix. FindPicoclawBinary() in web/backend/utils/runtime.go looks for
  picoclaw.exe on Windows, which didn't exist, causing gateway start to fail.

🧪 Test Environment

• Hardware: PC
• OS: Windows 10 19045, Git Bash (MINGW64)
• Model/Provider: N/A
• Channels: N/A

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

📸 Screenshots

[CLAassistant]

All committers have signed the CLA.

[yinwm]

Review Summary

Thanks for the contribution! This PR addresses the Windows build issue well.

Strengths

• ✅ Uses cp instead of ln -sf (avoids Windows symlink permission issues)
• ✅ Explicitly sets GOOS=windows GOARCH=amd64

Issues Found

1. Hardcoded ARCH=amd64 - The Windows detection branch hardcodes ARCH=amd64, which won't work correctly on ARM64 Windows devices (e.g., Surface Pro X). Consider detecting UNAME_M like the Linux/Darwin branches do.
2. Missing build-launcher-tui target - This target is not updated with EXE suffix handling.

Related PR

There's another PR #2051 that addresses the same issue (#2050) with:

• ✅ Dynamic ARCH detection (supports ARM64 Windows)
• ✅ Updated build-launcher-tui target
• ❌ Still uses ln -sf (symlink permission issue)
• ❌ No explicit GOOS/GOARCH setting

Suggestion: Please coordinate with @Alix-007 (author of #2051) to merge both PRs' strengths into one complete solution.