Skip getModule E2E tests on in-box Windows PowerShell

The `TestE2EPowerShell` build task launches the server with
`$env:PSModulePath = ''` (the vscode-powershell#3886 workaround for
inheriting `powershell.exe`'s module path). PSES's `UpdatePSModulePath()`
then appends the bundled module directory, so the runspace ends up with
`;<bundled>` — a non-empty path.

That distinction matters: Windows PowerShell only auto-injects its default
module locations (`$PSHOME\Modules`, etc.) when `PSModulePath` is empty. The
moment it's non-empty, no defaults are added, so `Get-Module -ListAvailable`
finds nothing and `powerShell/getModule` returns null for every module — not
just `Microsoft.PowerShell.Archive`. I confirmed this by probing
`powershell.exe` directly: an empty path resolves the module, while any
non-empty path (including the leading-`;` shape PSES produces) does not.
pwsh 7 isn't affected because `TestE2EPwsh` never clears the path, and real
VS Code sessions always have a populated `PSModulePath`, so the feature works
in practice.

This is a test-host artifact, not a product bug, so skip both getModule tests
on the in-box Windows PowerShell leg:

- `CanSendGetModuleRequestAsync` was failing outright (null module).
- `CanSendGetModuleRequestForMissingModuleAsync` was passing vacuously — it
  asserts null, which every module now returns — so it validated nothing on
  this leg. Promote it from `[Fact]` to `[SkippableFact]` and skip it too.

Both still run on Linux, macOS, and the PowerShell 7 Windows legs. This
mirrors the earlier `73293931e` skip that was reverted when we tried the
"probe Archive without skipping" approach, which the harness's emptied
`PSModulePath` makes unworkable.

Drafted by Copilot (Claude Opus 4.8).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: andyleejordan

test/PowerShellEditorServices.Test.E2E/LanguageServerProtocolMessageTests.cs

@@ -1306,11 +1306,14 @@ public async Task CanSendGetModuleRequestAsync()
             Skip.If(PsesStdioLanguageServerProcessHost.RunningInConstrainedLanguageMode,
                 "The getModule request's script doesn't work in Constrained Language Mode.");
 
-            // Probe a module that ships on disk in every host's module path so it
-            // resolves via Get-Module -ListAvailable everywhere. Windows PowerShell's
-            // in-box core modules (e.g. Microsoft.PowerShell.Management) are snap-in
-            // based and are not returned by -ListAvailable, whereas Microsoft.PowerShell.Archive
-            // is a file-based module on both Windows PowerShell and PowerShell 7+.
+            Skip.If(PsesStdioLanguageServerProcessHost.IsWindowsPowerShell,
+                "The Windows PowerShell E2E host launches with an emptied PSModulePath (see the TestE2EPowerShell build task and vscode-powershell#3886), so Get-Module -ListAvailable finds no modules and getModule can't resolve any module metadata.");
+
+            // Probe Microsoft.PowerShell.Archive: it's a file-based module (so it
+            // resolves via Get-Module -ListAvailable) that ships with both Windows
+            // PowerShell and PowerShell 7+, unlike the snap-in-based in-box core
+            // modules (e.g. Microsoft.PowerShell.Management) that -ListAvailable
+            // doesn't return.
             const string moduleName = "Microsoft.PowerShell.Archive";
 
             PSModuleMessage module =
@@ -1345,9 +1348,12 @@ await PsesLanguageClient
             Assert.Equal(module.Version, pinned.Version);
         }
 
-        [Fact]
+        [SkippableFact]
         public async Task CanSendGetModuleRequestForMissingModuleAsync()
         {
+            Skip.If(PsesStdioLanguageServerProcessHost.IsWindowsPowerShell,
+                "The Windows PowerShell E2E host launches with an emptied PSModulePath (see the TestE2EPowerShell build task and vscode-powershell#3886), so every module resolves to null and this test would pass vacuously rather than exercise the missing-module path.");
+
             PSModuleMessage module =
                 await PsesLanguageClient
                     .SendRequest(