Auto-detect Microsoft Store PowerShell 7 and add custom interpreter path setting

[cameronmid-lang]

Summary

This PR improves PowerShell 7 discovery by auto-detecting Microsoft Store package installations of pwsh.exe, adds a configurable custom interpreter path setting, supports direct executable paths in [ScriptHost(...)], and introduces an optional toggle to load PowerShell $PROFILE.

Context & Motivation

When PowerShell 7 is installed from the Microsoft Store (or via winget), its executable resides inside a package subdirectory:
%LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe

Previously, ScriptRunner.PwshInstallDirs() only checked the root of %LOCALAPPDATA%\Microsoft\WindowsApps without enumerating Microsoft.PowerShell* package subdirectories. When pwsh.exe was not found on PATH or in standard Program Files, PaletteShell silently fell back to Windows PowerShell 5.1 (powershell.exe).

In many managed or enterprise environments, Windows PowerShell 5.1 has execution restrictions enforced by policy, whereas PowerShell 7 runs without issue. This caused scripts to fail with authorization errors for users who installed PowerShell 7 from the Store.

Changes

1. Auto-Detect Store PowerShell Packages:

   • Updated ScriptRunner.PwshInstallDirs() to enumerate Microsoft.PowerShell* package subdirectories under %LOCALAPPDATA%\Microsoft\WindowsApps.

2. Custom PowerShell Path Setting:

   • Added customPowerShellPath (TextSetting) in PaletteShellSettingsManager.cs so users can explicitly configure an interpreter path in settings.
   • ScriptRunner.FindPwsh() checks this custom path first before scanning standard locations.

3. Direct Executable Path Support in [ScriptHost(...)]:

   • Updated ScriptRunner.ParseHost() and ScriptRunner.ResolveShell() to accept and validate direct file paths to executables (e.g. [ScriptHost('C:\path\to\pwsh.exe')]).
   • Updated ScriptCompatibilityValidator.cs to ensure valid custom paths pass compatibility checks.

4. Optional Profile Loading:

   • Added loadPowerShellProfile (ToggleSetting) in PaletteShellSettingsManager.cs. When enabled, -NoProfile is omitted from BuildProcessStartInfo, allowing scripts to load the user's PowerShell $PROFILE.

5. Tests & Documentation:

   • Added unit tests in ScriptRunnerTests.cs for host parsing, resolution, and WindowsApps directory discovery.
   • Updated PaletteShellScripts.AGENTS.md, PaletteShellScripts.Reference.md, and extension-behavior-reference.md.

Validation

• Verified that PwshInstallDirs() discovers the Microsoft Store package folder.
• Unit tests added to ScriptRunnerTests.cs for standard and custom executable host parsing.

[paletteshell]

Just FYI, I am still working on testing these changes and making a few modifications.

The loading of a profile can break certain functionality if the profile had things in it that would echo output for example.