fix(core): resolve Windows shells installed as app-execution aliases

[Hotragn]

Issue for this PR

Closes #41426

Type of change

• Bug fix

What does this PR do?

A shell installed from the Microsoft Store — most commonly pwsh — is not found, so setting shell: "pwsh" silently falls back to Windows PowerShell 5.1.

Store/MSIX installs expose their executable as an app-execution alias: a zero-byte AppExecLink reparse point on PATH. CreateProcess resolves it by name, but stat reports nothing and which skips it. executable() in shell/select.ts resolves non-rooted names through which, so the shell comes back as "not installed" and selection moves on without telling the user.

Measured on a Windows 11 box, using winget (always an alias) as the probe:

probe	result
fs.existsSync(alias)	false
fs.statSync(alias)	undefined
spawnSync("winget")	status 0

where.exe does see aliases, so it distinguishes "installed as an alias" from "not installed". The fallback is scoped narrowly: win32 only, only for a name already in META, and only after which has failed — so it cannot make an unrelated or absent binary resolve.

This also looks like the root cause behind #30615 and #17372.

How did you verify your code works?

packages/core/test/shell.test.ts — 11/11 pass. Added a case asserting that a known-but-absent shell (zsh, ksh) still falls back rather than resolving to its own bare name, which is the regression this fallback could otherwise introduce. Verified where.exe returns 0 for an installed alias and 1 for an absent shell on the same machine.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR fix(core): resolve Windows shells installed as app-execution aliases #43323: fix(core): resolve Windows shells installed as app-execution aliases
  • fix(core): resolve Windows shells installed as app-execution aliases #43323

Why it's related: This PR has the exact same title and addresses the same issue (Windows Store/MSIX shell installations not being resolved). It appears to be a previous attempt at the same fix. You should verify whether #43323 is still open, closed, or merged, and consider whether this PR (48968) supersedes it or if there's redundant work being done.

[Hotragn]

The needs:issue label looks like it was applied before the description was saved — the body does link the issue (Closes #41426, which is open). Happy to adjust the wording if the check wants a different format.

[Hotragn]

Confirming the flag: #43323 is mine and is the same fix targeting dev. This one targets v2, which AGENTS.md on that branch asks PRs to default to, and it is not a cherry-pick — the resolution logic moved to shell/select.ts (executable()), so it needed porting. It also carries the review feedback from #43323: memoized lookups and an absolute path instead of a bare name. Happy to close #43323 in favour of this one if that's cleaner.