Windows updater invokes legacy powershell.exe (5.1) instead of pwsh 7, breaking update on systems without WMF

Bug

codex update (auto-triggered on CLI start) on Windows shells out to powershell.exe (Windows PowerShell 5.1) instead of pwsh.exe (PowerShell 7+). On a system where PowerShell 7 is installed but 5.1's Get-FileHash fails to resolve (e.g. profile/module load issue), the update fails:

Updating Codex via `powershell -ExecutionPolicy Bypass -c '$env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex'`...
==> Updating Codex CLI from 0.153.2 to 0.153.4
==> Detected platform: Windows (x64)
==> Resolved version: 0.153.4
==> Downloading Codex CLI
WARNING: Could not download or verify .../SHA256SUMS; retrying from GitHub Releases.
iex : The term 'Get-FileHash' is not recognized as the name of a cmdlet, function, script file, or operable program.
Error: `powershell -ExecutionPolicy Bypass -c ...` failed with status exit code: 1

where powershell on this machine resolves to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe (5.1), while pwsh.exe (7.x) is also installed and on PATH. The updater hardcodes powershell, never checking for/preferring pwsh.

Expected

Updater should prefer pwsh.exe when present on PATH, falling back to powershell.exe only if pwsh is unavailable. This avoids environment-specific breakage on the legacy Windows PowerShell shell.

Environment

• codex-cli 0.153.4 (Windows x64)
• Windows PowerShell 5.1 present at default path
• PowerShell 7 present at C:\Program Files\PowerShell\7\pwsh.exe

Workaround

Manually run the install script under pwsh:

pwsh -c '$env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex'

Start with the Windows updater path exercised by codex update and the command shown in the issue. Check how the installer command selects powershell.exe, then verify the completed behavior prefers pwsh.exe when available and falls back to powershell.exe when it is not.