Run a function added as a CommandInfo in its own module scope - #28187

A script function passed to the pipeline as a CommandInfo (PowerShell.AddCommand(CommandInfo)) runs in the caller's session state instead of its module's. LocalPipeline.CreateCommandProcessBase creates the CommandProcessor with LocalRunspace.ExecutionContext.EngineSessionState, while command discovery (CommandDiscovery.CreateCommandProcessorForScript / GetScriptAsCmdletProcessor) uses functionInfo.ScriptBlock.SessionStateInternal. As a result, a module function invoked this way cannot see its $script: variables or the module's private functions, whereas the same function invoked by name works.

This PR makes CreateCommandProcessBase use the function's own session state, falling back to the engine session state as before.

Repro (same result on Windows PowerShell 5.1 and PowerShell 7.6):

New-Module -Name ReproMod -ScriptBlock {
    $script:Target = { "called with $args" }
    function Get-PrivateValue { 'private' }
    function Invoke-Repro { & $script:Target (Get-PrivateValue) }
    Export-ModuleMember -Function Invoke-Repro
} | Import-Module

$ps = [powershell]::Create('CurrentRunspace')
$ps.AddCommand((Get-Command ReproMod\Invoke-Repro)).Invoke()   # nothing
$ps.Streams.Error   # The term 'Get-PrivateValue' is not recognized ...

Invoke-Repro                                                   # called with private

PR Context

The Hyper-V module hits this on PowerShell 7 for every change to a clustered VM. After Add-VMHardDiskDrive, Remove-VMHardDiskDrive and similar cmdlets, Microsoft.HyperV.PowerShell.ClusterUtilities.UpdateClusterVMConfiguration looks up FailoverClusters\Update-ClusterVirtualMachineConfiguration and runs it with PowerShell.Create(RunspaceMode.CurrentRunspace).AddCommand(commandInfo). On PowerShell 7, FailoverClusters is loaded through the Windows PowerShell compatibility session, so the command is an implicit-remoting proxy function. Its body calls & $script:InvokeCommand ..., and because it runs outside its module, $script:InvokeCommand is $null:

Microsoft.HyperV.PowerShell.VirtualizationException: The Update-ClusterVirtualMachineConfiguration command could not be completed.
 ---> System.Management.Automation.RuntimeException: The expression after '&' in a pipeline element produced an object that was not valid.
      It must result in a command name, a script block, or a CommandInfo object.
   at Microsoft.HyperV.PowerShell.ClusterUtilities.UpdateClusterVMConfiguration(...)

The VM change is applied, but the cluster's VM configuration is not refreshed. Invoking the same proxy function by name, or with AddCommand("FailoverClusters\Update-ClusterVirtualMachineConfiguration"), succeeds. That is the behaviour this PR gives the CommandInfo path.

Related, but not changed here: for a module-qualified name, CommandInvocationIntrinsics.GetCommand(name, CommandTypes.Cmdlet) also returns functions. The module auto-loading branch (CommandDiscovery.TryModuleAutoLoading) does not apply the CommandTypes filter, which is why the Hyper-V module receives the proxy function in the first place. This has been the behaviour since Windows PowerShell, and callers such as the Hyper-V module now depend on it: with the filter applied they would skip the cluster refresh with only a warning.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge. If this PR is a work in progress, please open this as a Draft Pull Request and mark it as Ready to Review when it is ready to merge.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed

Tests added to test/powershell/engine/Api/PSCommand.Tests.ps1:

• a module function added as a CommandInfo sees its $script: variables and private functions. It fails on 7.5.4 with "The term 'Get-PrivateValue' is not recognized" and passes with this change;
• a global function added as a CommandInfo keeps working (no change in behaviour).