Terminal: user-overridden built-in "PowerShell" profile path is ignored on Windows, falls back to Windows PowerShell 5.1

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.138.0
- OS Version: Windows 11 (build 26100)

Steps to Reproduce:

1. Install PowerShell 7 to a non-standard location, e.g. `E:\PowerShell\7\pwsh.exe`
(NOT under `%ProgramFiles%\PowerShell`, not Store, not Scoop, not `~/.dotnet/tools`).
2. Ensure `pwsh.exe` resolves on PATH (`where pwsh` -> `E:\PowerShell\7\pwsh.exe`).
3. In user `settings.json`:

```json
"terminal.integrated.defaultProfile.windows": "PowerShell",
"terminal.integrated.profiles.windows": {
"PowerShell": {
"icon": "terminal-powershell",
"path": [
"pwsh.exe",
"E:\\PowerShell\\7\\pwsh.exe",
"powershell.exe",
"C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
]
}
}
```

4. Open a new integrated terminal.

Expected: PowerShell 7 (`E:\PowerShell\7\pwsh.exe`) is launched, since the user
explicitly provided `pwsh.exe` / the full pwsh 7 path first.

Actual: Windows PowerShell 5.1 is launched. The renderer log shows:

```
"creationOptions":{"shellPath":"C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"}
```

and inside the terminal `$PSVersionTable.PSVersion` reports `5.1.26100.9444`.

Analysis:

- The built-in `PowerShell` profile (`source: "PowerShell"`) is resolved by an
auto-detection function that only scans:
`%ProgramFiles%\PowerShell\\pwsh.exe`, `%ProgramFiles(x86)%`, the store
package dir, `~/.dotnet/tools/pwsh.exe`, `~/.scoop/apps/pwsh/current/pwsh.exe`,
and finally falls back to
`%windir%\System32\WindowsPowerShell\v1.0\powershell.exe` (5.1).
- A user-provided `path` for the reserved profile name `PowerShell` does not
change this resolution: the built-in detection result is used, so a
custom-location pwsh 7 install is never found and 5.1 is used instead.
- The JSON schema for `terminal.integrated.profiles.windows` accepts
`{ "path": [ ... ] }` for `PowerShell`, which strongly implies the user's path
should be honored. Right now it is silently ignored.

This is very easy to hit because PowerShell 7's installer allows an arbitrary
install directory, and `source: "PowerShell"` cannot express a custom path.

Suggestions (either would fix it):

1. When the user explicitly specifies `path` for a profile, honor that path and
do not replace it with the built-in auto-detected shell (i.e. treat an
explicit user `path` as authoritative, even for reserved profile names).
2. Or, if overriding built-in profiles by name is intentionally unsupported,
document it and/or warn the user that the `PowerShell` profile name is
reserved and that a distinct profile name must be used for a custom install.

Related: #300624 is about an extension hardcoding `C:\Program Files\PowerShell\7`,
which is a different (downstream) symptom of the same custom-install problem.