$psEditor does not handle 32/64 bit file redirection

PSES is properly running in a 64bit context, but when it passes a path to be opened in VSCode it is being redirected to the 32bit path.

Example:

Register-EditorCommand `
    -Name 'PowerShellEditorServices.OpenAllUserEditorProfile' `
    -DisplayName 'Open All User Editor Profile' `
    -SuppressOutput `
    -ScriptBlock {
        param([Microsoft.PowerShell.EditorServices.Extensions.EditorContext]$context)

        $ProfilePath = Join-Path -Path $PShome -ChildPath 'Microsoft.VSCode_profile.ps1'
        If (!(Test-Path -Path $ProfilePath)) { New-Item -Path $ProfilePath -ItemType File }

        $psEditor.Workspace.OpenFile($ProfilePath)
    }

The Editor Command properly creates

"C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1"

Then when the same path is passed to $psEditor.Workspace.OpenFile and it is passing it to VSCode to open, Code is not handling the 32/64 redirect. This has terrible consequences for the user.

Code the attempts to open the following path:

"C:\Windows\sysWOW64\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1"

The command silently fails because the item does not exist.

As a temporary workaround you could pass $psEditor this path and it will work:

"C:\Windows\sysnative\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1"

This is not really a good solution and really should be addressed by VSCode. If they never plan on making a 64 bit client, they need to be handling 32/64 redirect. However, since I really don't think that will happen(or if it does, its likely not anytime soon), maybe we can get PSES handling this by passing the sysnative path if PSES is running in a 64 bit context.

Start by tracing the $psEditor.Workspace.OpenFile entry point and how it passes Windows paths to VSCode. Reproduce the 32/64-bit redirection with the provided profile-path example, then compare it with the sysnative workaround. Done means a valid 64-bit path opens without silently targeting the nonexistent sysWOW64 path.