fix(windows): read search_code temp files as UTF-8

[Cosm1cAC]

Summary

search_code can miss matches on Windows when the indexed project is under a non-ASCII path, such as a CJK directory name.

Scoped search writes two temporary files: one for the pattern and one for the indexed file list. Both files are UTF-8. The Windows command builder was reading them back with plain Get-Content before handing each path to Select-String -LiteralPath.

That is fragile on Windows PowerShell 5.1. UTF-8 without a BOM is decoded with the local ANSI code page unless the encoding is explicit. A path like C:/Users/.../移动版agent终端/src/file.js is read back as mojibake, so Select-String receives a literal path that does not exist and search_code returns a clean zero-match result.

This patch makes the Windows search_code command builder read the pattern file and scoped file list with Get-Content -Encoding UTF8 -LiteralPath.

Related to #903.

Reproduction

I reproduced this on Windows PowerShell 5.1 with a project rooted under:

C:/Users/<user>/Documents/移动版agent终端

and a source file containing agentReachCommandForAction.

Before the fix:

• Select-String -LiteralPath <actual file> -Pattern agentReachCommandForAction finds the expected lines.
• The scoped search_code pipeline reads the UTF-8 file list through plain Get-Content.
• The CJK path is decoded as mojibake, so Test-Path -LiteralPath <decoded path> is false.
• search_code returns zero grep matches.

After the fix:

• The same file list is read with Get-Content -Encoding UTF8 -LiteralPath.
• The decoded path exists.
• Select-String finds the expected matches.

Verification

Local command-level check on Windows PowerShell 5.1:

• current pipeline: current_matches=0
• patched pipeline: patched_matches=2
• default-decoded filelist path exists: False
• UTF-8-decoded filelist path exists: True

Also ran:

• git diff --check

I added a Windows-only regression test that creates a scoped search_code fixture under a UTF-8 CJK project root.

I could not run the full native Windows C test suite locally because this machine does not have the MSYS2/CLANG64 GNU Make toolchain used by the Windows CI job. Visual Studio cl is installed, but that is not this project's Windows CI build path.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[DeusData]

Thanks for covering the Windows UTF-8 temp-file path. Triage: Windows query/read bug, high priority because it affects non-ASCII projects after indexing. Review focus is PowerShell 5.1 encoding behavior, CJK path coverage, and no regression to POSIX temp-file reads.

[DeusData]

Merged — thank you! Surgical fix with the right PS 5.1 root cause (BOM-less UTF-8 decoded as ANSI), and the test locks it in. The Windows non-ASCII path class keeps biting; this closes another corner of it. Much appreciated.