PR #2328 reset the three E2E test files to their pre-#2318 state
(`b57653c40`) to undo the Windows PowerShell skips we no longer want now
that the host-start hang is actually fixed. But #2318 was a squash that
bundled genuine harness hardening *alongside* those skips, so reverting
wholesale quietly dropped the good parts too. Restore just those, keeping
the skips reverted:

- `ReadScriptLogLineAsync` now yields with `await Task.Delay(100)` at EOF
  instead of busy-spinning. At EOF `ReadLineAsync` completes synchronously
  with `null`, so the old `while`/`await` loop never released its
  thread-pool thread and could starve the scheduler on constrained CI
  runners.
- The child-process `Debug-Runspace` readiness poll in
  `CanAttachScriptWithPathMappings` sleeps 100ms per iteration so it can't
  peg a core during the attach handshake.
- `LSPTestsFixture.DisposeAsync` guards against a null `PsesLanguageClient`
  so a startup failure isn't masked by a `NullReferenceException` during
  teardown.

These are defense-in-depth independent of the skips, and they matter more
now that we un-skip: a Windows PowerShell server that fails to start
shouldn't busy-spin or NRE on teardown.

Drafted by Copilot (Claude Opus 4.8).

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

This PR un-skips `CanAttachScriptWithPathMappings` on Windows PowerShell
(reverting the #2318 skips now that the host-start hang is fixed), and the
un-skipped test promptly failed on the WinPS 5.1 CI leg with "Attached
process exited before the script could start" -- at exactly 10 seconds.

The test spawns a child `powershell.exe`, then waits up to 10s for
`Debug-Runspace` to subscribe to the child's runspace as the marker that
the attach handshake completed, before driving a full breakpoint/continue
interaction under a 15s xUnit timeout. On the 2-vCPU CI runners the WinPS
attach alone exceeds that 10s budget, so the child throws its internal
timeout and exits before the debug session attaches. It isn't even close
to comfortable locally: xUnit flags the run as a long-running test at the
10s mark on a fast dev box, so the old budget was always on a knife's edge
for the slower WinPS path.

Rather than re-skip it, give the slow-but-correct path room:

- The child's `Debug-Runspace` subscription poll goes 10s -> 30s.
- The outer process-watch cancellation goes 30s -> 60s.
- The xUnit `Timeout` goes 15s -> 60s.

This continues 81b273b (which already bumped the xUnit timeout 10s -> 15s
for the same flakiness) and keeps real coverage of the attach path on
Windows PowerShell instead of skipping it. See #2323 and #2318.

Drafted by Copilot (Claude Opus 4.8).

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

Un-skipping the entire Windows PowerShell E2E suite (now that the host-start
hang is fixed) gave us real WinPS coverage for the first time since #2318, but
it also surfaced two pre-existing WinPS-specific failures that have nothing to
do with host startup:

- `CanAttachScriptWithPathMappings` wedges on the in-box, cross-process
  `Debug-Runspace` attach handshake and rides whatever timeout we set. CI
  failed it at 10s, then again at exactly 30s after I bumped the budgets, so
  it genuinely never completes rather than merely running slow. This is the
  in-box attach deadlock tracked by #2323.
- `CanSendCompletionResolveWithModulePrefixRequestAsync` gets an empty
  completion list from the Windows PowerShell server for a prefix-imported
  command (it fails before any help assertion, so it's help-independent).
  That's the same "completion works in PS7 but not WinPS" family as #1355.

Because startup no longer hangs, we don't need #2318's discovery-time
`[SkippableFactOnWindowsPowerShell]` attribute anymore: an in-body
`Skip.If(IsWindowsPowerShell, ...)` runs after `InitializeAsync` (which now
starts the server fine) and skips before the broken code, so both tests skip
cleanly in ~1ms under `powershell.exe` instead of hanging or failing.

This also reverts my earlier timeout bump on `CanAttachScriptWithPathMappings`
(back to the 15s/10s/30s budgets from `main`) since the bigger budgets didn't
help and the test no longer runs on Windows PowerShell anyway. Everything else
stays un-skipped.

Drafted by Copilot (Claude Opus 4.8).

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

…#2328)

* Fix Windows PowerShell host-start hang in `SetCorrectExecutionPolicy`

On recent in-box Windows PowerShell 5.1 servicing builds, the language and
debug servers intermittently hang on startup and ride the CI job timeout
(#2323). The wedge is `SetCorrectExecutionPolicy`: it calls
`Microsoft.PowerShell.Security\Get-ExecutionPolicy -List`, which autoloads
`Microsoft.PowerShell.Security` into the freshly created runspace. That
runspace's `InitialSessionState` is reused from the host runspace and already
carries the module's `ObjectSecurity` type data, so re-binding it throws "The
member `AuditToString` is already present". `PsesInternalHost.Run()` catches
it, faults `_started`, and the pipeline thread exits — but `TryStartAsync` is
still awaiting queued startup tasks that now never run, so it hangs forever.

Configuring the execution policy is best-effort, so we wrap the
`Get-ExecutionPolicy` query in try/catch (mirroring the existing
`Set-ExecutionPolicy` handling just below it) and skip policy configuration
when it fails, rather than letting a type-data hiccup abort host startup. I
also guard the subsequent indexing against a short result list.

With the hang fixed we no longer need the in-box Windows PowerShell E2E skips
added in #2318, so this reverts them: the `SkippableFactOnWindowsPowerShell`
attributes, the `LSPTestsFixture` early-return, and the two attribute files.
The DAP suite passes clean under `powershell.exe`. Three LSP help tests
(`Expand-Archive` synopsis) still fail locally on my older servicing build
(.8655); they pass under `pwsh`, so I'm letting CI judge them on its build
rather than re-skipping. The `ci-test.yml` job timeout from #2318 stays as a
backstop.

Drafted by Copilot (Claude Opus 4.8).

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

* Restore E2E test hardening reverted with the Windows PowerShell skips

PR #2328 reset the three E2E test files to their pre-#2318 state
(`b57653c40`) to undo the Windows PowerShell skips we no longer want now
that the host-start hang is actually fixed. But #2318 was a squash that
bundled genuine harness hardening *alongside* those skips, so reverting
wholesale quietly dropped the good parts too. Restore just those, keeping
the skips reverted:

- `ReadScriptLogLineAsync` now yields with `await Task.Delay(100)` at EOF
  instead of busy-spinning. At EOF `ReadLineAsync` completes synchronously
  with `null`, so the old `while`/`await` loop never released its
  thread-pool thread and could starve the scheduler on constrained CI
  runners.
- The child-process `Debug-Runspace` readiness poll in
  `CanAttachScriptWithPathMappings` sleeps 100ms per iteration so it can't
  peg a core during the attach handshake.
- `LSPTestsFixture.DisposeAsync` guards against a null `PsesLanguageClient`
  so a startup failure isn't masked by a `NullReferenceException` during
  teardown.

These are defense-in-depth independent of the skips, and they matter more
now that we un-skip: a Windows PowerShell server that fails to start
shouldn't busy-spin or NRE on teardown.

Drafted by Copilot (Claude Opus 4.8).

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

* Fail fast when the debug adapter's `OnInitialize` delegate throws

OmniSharp's `DebugAdapterServer.From()` (0.19.9) awaits an internal
`AsyncSubject` that its `InitializeRequest` handler only signals on the
success path. If an `OnInitialize` delegate throws, the handler faults
before signaling, nothing errors the subject, and `From()` -- and thus
`PsesDebugServer.StartAsync()` -- awaits it forever. So a startup failure
wedges the entire debug server and rides the CI/job timeout instead of
failing fast. This is a library limitation, not our bug: the same code is
present on the library's `master`, so we can't fix it upstream without a
fork or upgrade.

#2328 fixes the specific trigger we hit on in-box Windows PowerShell (the
`Get-ExecutionPolicy -List` type-data conflict), but the wedge mechanism is
generic. Guard against any future `OnInitialize` failure: wrap the delegate
body, log the exception, and signal `_serverStopped` so `WaitForShutdown`
unblocks and the process exits cleanly. `Dispose`'s `_serverStopped`
completion is now idempotent (`TrySetResult`) since the catch may have
already completed it.

This converts a silent multi-hour hang into a clean termination with a
logged error -- the client sees the session end instead of waiting forever.
See #2323.

Drafted by Copilot (Claude Opus 4.8).

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

* Increase `CanAttachScriptWithPathMappings` timeouts on slow CI runners

This PR un-skips `CanAttachScriptWithPathMappings` on Windows PowerShell
(reverting the #2318 skips now that the host-start hang is fixed), and the
un-skipped test promptly failed on the WinPS 5.1 CI leg with "Attached
process exited before the script could start" -- at exactly 10 seconds.

The test spawns a child `powershell.exe`, then waits up to 10s for
`Debug-Runspace` to subscribe to the child's runspace as the marker that
the attach handshake completed, before driving a full breakpoint/continue
interaction under a 15s xUnit timeout. On the 2-vCPU CI runners the WinPS
attach alone exceeds that 10s budget, so the child throws its internal
timeout and exits before the debug session attaches. It isn't even close
to comfortable locally: xUnit flags the run as a long-running test at the
10s mark on a fast dev box, so the old budget was always on a knife's edge
for the slower WinPS path.

Rather than re-skip it, give the slow-but-correct path room:

- The child's `Debug-Runspace` subscription poll goes 10s -> 30s.
- The outer process-watch cancellation goes 30s -> 60s.
- The xUnit `Timeout` goes 15s -> 60s.

This continues 81b273b (which already bumped the xUnit timeout 10s -> 15s
for the same flakiness) and keeps real coverage of the attach path on
Windows PowerShell instead of skipping it. See #2323 and #2318.

Drafted by Copilot (Claude Opus 4.8).

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

* Skip the attach and prefixed-completion E2E tests on Windows PowerShell

Un-skipping the entire Windows PowerShell E2E suite (now that the host-start
hang is fixed) gave us real WinPS coverage for the first time since #2318, but
it also surfaced two pre-existing WinPS-specific failures that have nothing to
do with host startup:

- `CanAttachScriptWithPathMappings` wedges on the in-box, cross-process
  `Debug-Runspace` attach handshake and rides whatever timeout we set. CI
  failed it at 10s, then again at exactly 30s after I bumped the budgets, so
  it genuinely never completes rather than merely running slow. This is the
  in-box attach deadlock tracked by #2323.
- `CanSendCompletionResolveWithModulePrefixRequestAsync` gets an empty
  completion list from the Windows PowerShell server for a prefix-imported
  command (it fails before any help assertion, so it's help-independent).
  That's the same "completion works in PS7 but not WinPS" family as #1355.

Because startup no longer hangs, we don't need #2318's discovery-time
`[SkippableFactOnWindowsPowerShell]` attribute anymore: an in-body
`Skip.If(IsWindowsPowerShell, ...)` runs after `InitializeAsync` (which now
starts the server fine) and skips before the broken code, so both tests skip
cleanly in ~1ms under `powershell.exe` instead of hanging or failing.

This also reverts my earlier timeout bump on `CanAttachScriptWithPathMappings`
(back to the 15s/10s/30s budgets from `main`) since the bigger budgets didn't
help and the test no longer runs on Windows PowerShell anyway. Everything else
stays un-skipped.

Drafted by Copilot (Claude Opus 4.8).

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

* Skip the flaky child-attach-session E2E test on Windows PowerShell

Un-skipping the Windows PowerShell E2E suite surfaced one more attach-family
flake: `CanLaunchScriptWithNewChildAttachSession`. It passed on the prior CI run
(`a4e8a823e`) but timed out (`TaskCanceledException` at its 30s budget) on the
next (`25d9e58dd`) with no relevant code change in between, so it's genuinely
flaky on the slow in-box Windows PowerShell CI runners rather than broken.

The test runs `Start-DebugAttachSession` and waits for the server's
`startDebugging` reverse-request round-trip; on in-box Windows PowerShell that
round-trip is slow enough to intermittently miss the timeout. That's the same
in-box attach-E2E reliability bucket as #2323, and its two siblings are already
skipped there: `CanAttachScriptWithPathMappings` (the cross-process
`Debug-Runspace` wedge) and `CanLaunchScriptWithNewChildAttachSessionAsJob`
(no `ThreadJob` on Windows PowerShell). So skip this one on Windows PowerShell
too, keeping the rest of the now-un-skipped DAP suite running.

The flake only reproduces on the constrained CI runner, not on a fast dev box,
so I'm matching how the sibling attach tests are handled rather than chasing a
timeout bump I can't validate locally.

Drafted by Copilot (Claude Opus 4.8).

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

---------

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