docs: add a Windows known-issues / troubleshooting section

[oscarbol09]

What

Propose adding a docs/WINDOWS_TROUBLESHOOTING.md (or a dedicated section in the README) that centralizes the recurring Windows-specific problems currently being reported, with known symptoms → likely cause → workaround, so new Windows users have somewhere to look before opening a duplicate issue.

Why

The issue tracker currently has a cluster of distinct-looking but related Windows reports, several opened within the same week:

• Windows: CBM_CACHE_DIR / CBM_ALLOWED_ROOT are lossily decoded — every non-ASCII char becomes U+FFFD, so the server silently uses a different path (v0.9.0) #1165 — CBM_CACHE_DIR / CBM_ALLOWED_ROOT lossily decoded (non-ASCII → U+FFFD), causing silent path divergence or hard failures
• Can't upgrade codebase-memory-mcp on windows platform. Can't uninstall. #1168 — codebase-memory-mcp upgrade reports success but the binary version doesn't actually change
• Worker continuously hangs and indexing process gives up eventually #1130, Indexing worker can freeze the whole OS on binary-heavy folders, and always dies with a 0-byte log — needs resource guards and early log flush #1132, Windows-Indexing worker crashed on a file #1145 — indexing worker hangs/crashes with a 0-byte log, no way to diagnose which file caused it
• Installer targets legacy Gemini-CLI settings.json instead of Antigravity 2.0 config directory (resulting in duplicate 273MB binaries) #1161 — installer targets the legacy Gemini-CLI settings.json instead of the Antigravity 2.0 modular config, and can leave duplicate 273MB binaries on disk
• fails to install for opencode on windows (other os's unknown) #1167 — install fails to detect OpenCode on Windows even when both the CLI and app are installed

Each is already tracked individually and should stay that way for the actual fixes, but a lot of the diagnostic value (e.g. "if config list fails with cannot open config database, check for non-ASCII in your Windows username — see #1165") is currently locked inside individual issue threads. A short troubleshooting doc would reduce duplicate reports and give maintainers something to link to when triaging new Windows issues.

Proposal

• New file: docs/WINDOWS_TROUBLESHOOTING.md, linked from the README's existing Troubleshooting table.
• Structure: one entry per known class of problem (symptom, root cause if known, workaround if one exists, link to the tracking issue), kept in sync as those issues get fixed/closed.
• Scope is documentation only — no code changes, so it doesn't touch any of the higher-risk areas in MAINTAINERS.md.

Happy to draft the content and open a PR once the location/format is confirmed by a maintainer, per the "open an issue first" contribution guideline.