[BUG] install.ps1 crashes on Windows PowerShell 5.1: IndexOutOfRangeException in Invoke-WebRequest during binary download

Environment

• OS: Windows 10/11 (win32-x64)
• Shell: Windows PowerShell 5.1 (powershell.exe)
• Install command: irm https://code.kimi.com/kimi-code/install.ps1 | iex
• Version being installed: 0.26.0

Steps to reproduce

1. Open Windows PowerShell 5.1.
2. Run irm https://code.kimi.com/kimi-code/install.ps1 | iex.
3. The script resolves the latest version (0.26.0) and fetches the manifest successfully.
4. It crashes at the binary download step.

Expected behavior

The binary downloads, the checksum is verified, and the install completes.

Actual behavior

`Invoke-WebRequest -Uri $binaryUrl -OutFile $tmpBinary` (install.ps1:353) throws
`System.IndexOutOfRangeException` ("索引超出了数组界限" / "Index was outside the bounds of the array"):

================ DEBUG: FULL ERROR ================
ExceptionType         : System.IndexOutOfRangeException
Message               : 索引超出了数组界限。
FullyQualifiedErrorId : System.IndexOutOfRangeException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
CategoryInfo          : NotSpecified: (:) [Invoke-WebRequest], IndexOutOfRangeException
Line                  :   Invoke-WebRequest -Uri $binaryUrl -OutFile $tmpBinary
PositionMessage       : 所在位置 行:353 字符: 3
+   Invoke-WebRequest -Uri $binaryUrl -OutFile $tmpBinary
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ScriptStackTrace:
在 <ScriptBlock>、<无文件> 中: 第 353 行
在 <ScriptBlock>、<无文件> 中: 第 1 行
===================================================

Analysis

• The download URL itself is healthy: https://code.kimi.com/kimi-code/binaries/0.26.0/kimi-code-win32-x64.exe
  → 302 → https://cdn.kimi.com/kimi-code/binaries/0.26.0/kimi-code-win32-x64.exe → 200,
  129,455,104 bytes (~123.4 MiB), SHA256 96b056f4560810f243731988a01c79844723fa2712c4d66337a92ef00cd6a1ed
  (matches manifest.json). Other download tools (curl.exe, browsers, PowerShell 7) fetch it without issues.
• IndexOutOfRangeException is an internal CLR exception, not a normal network error (which would
  surface as a WebException: timeout / TLS failure / connection refused). It indicates a bug in the
  .NET Framework HTTP stack that PowerShell 5.1's Invoke-WebRequest is built on, triggered while
  processing this response (302 redirect + large payload). On affected machines this is typically
  provoked by environment factors such as system proxy auto-detect (WPAD/PAC) or antivirus software
  intercepting the response — but the script should be robust against that.
• Note that install.ps1:353 is the only Invoke-WebRequest call in the script without
  -UseBasicParsing (line 329 has it), and it is also the only large-file (-OutFile, ~123 MB) request.

Suggested fixes

1. Add -UseBasicParsing to the download call (line 353) for consistency with line 329.
2. For the large binary, prefer curl.exe (bundled with Windows since 10 1803) or
   System.Net.Http.HttpClient / Start-BitsTransfer over PS 5.1 Invoke-WebRequest,
   ideally with a fallback chain.
3. On download failure, print actionable guidance: the manual download URL, the expected SHA256,
   the target path (%USERPROFILE%\.kimi-code\bin\kimi.exe), and the npm alternative
   (npm install -g @moonshot-ai/kimi-code).

Workaround for affected users

curl.exe -L -o "$env:TEMP\kimi.exe" https://code.kimi.com/kimi-code/binaries/0.26.0/kimi-code-win32-x64.exe
Get-FileHash "$env:TEMP\kimi.exe" -Algorithm SHA256 # expect 96B056F4560810F243731988A01C79844723FA2712C4D66337A92EF00CD6A1ED
New-Item -ItemType Directory -Force "$env:USERPROFILE.kimi-code\bin" | Out-Null
Copy-Item "$env:TEMP\kimi.exe" "$env:USERPROFILE.kimi-code\bin\kimi.exe" -Force

then add %USERPROFILE%.kimi-code\bin to the user PATH

Related: #1513 (install.ps1 robustness issues on Windows)

Start in install.ps1 at line 353 and compare the large binary download with the Invoke-WebRequest call at line 329, which uses -UseBasicParsing. Reproduce the install in Windows PowerShell 5.1, then verify that the binary downloads, its SHA256 matches the manifest, and installation completes; if a fallback is added, test the documented curl.exe path as well.