fix: stop garbled Chinese output from where-based binary detection on Windows

[shanren]

What

npm start output on zh-CN Windows was full of mojibake (锟斤拷…). Every provider whose binary is not installed made the app shell out to where, which prints a localized (GBK) "not found" message straight to the terminal even when stderr is piped, and Node's utf-8 decode irreversibly turned the GBK bytes into U+FFFD.

Root cause

• src/main/providers/resolve-binary.ts ran where "<binary>" via execSync to resolve CLI binaries; on zh-CN Windows a missing binary prints 信息: 用提供的模式无法找到文件。 directly to the console and exits non-zero.
• Same pattern in src/main/prerequisites.ts (where claude).
• where output is GBK (code page 936); encoding: 'utf-8' produced replacement chars that render as 锟斤拷 mojibake in the terminal.

Fix

On Windows, replace the where subprocess with a pure-Node walk of the augmented PATH (findBinaryInDir / fs.existsSync, checking .cmd/.exe/.ps1/bare) — no subprocess, no localized output, no encoding hazard. macOS/Linux still use which (no localization issue). The identical latent bug in prerequisites.ts is fixed the same way.

Verification

• Full suite green (1777 tests), npm run build passes
• Captured 12s of startup output: 0 mojibake lines, provider warnings intact
• New regression tests assert where is never shelled out to on Windows

🤖 Generated with Claude Code