fix(windows): revert unsafe PowerShell alias probing

[marius-kilocode]

What Problem This Solves

Kilo CLI and the VS Code extension can fail before startup on Windows when the Microsoft Store PowerShell 7 execution alias exists at %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe but cannot be inspected. The probe added in PR #13365 calls statSync on that alias, which raises EACCES instead of returning a missing entry.

This affects both Bun 1.4 and Bun 1.3.14. Removing Store PowerShell 7 makes startup work because the protected alias disappears.

Why This Change Was Made

Revert PR #13365 for the emergency release instead of adding another unproven filesystem workaround. This restores the exact shell-selection behavior used before the regression:

• Use PowerShell 7 when pwsh is available on PATH.
• Honor explicit shell configuration.
• Otherwise use Windows PowerShell 5.1 or the existing fallback shell.
• Do not probe protected WindowsApps execution aliases or off-PATH install locations.

User Impact

Windows users with both PowerShell 5.1 and Store PowerShell 7 can start the CLI and extension again. Users who want PowerShell 7 selected must keep pwsh on PATH or configure it explicitly until safe off-PATH detection is reintroduced separately.

Evidence

• User reports confirm startup succeeds when Store PowerShell 7, and therefore the protected alias, is removed.
• The v7.5.4 stack points directly to the PR fix: prefer PowerShell 7 over legacy Windows PowerShell 5.1 #13365 statSync filter and reports EACCES for WindowsApps\pwsh.exe.
• Core, CLI, and extension typechecks passed.
• 15 affected shell and Agent Manager command tests passed.
• Extension lint, knip, conflict-marker, annotation, and diff checks passed.

Fixes #13467 and #13473. Reverts #13365.