Support provider-backed workspace URIs via pspath

[dkattan]

Summary

• add pspath:// document support so provider-backed scripts can participate in workspace operations without pretending to be file:// paths
• route provider-backed workspace enumeration and content reads through PowerShell cmdlets when a host is available
• keep normal file-backed documents and workspace traversal on direct filesystem I/O to avoid cross-thread/apartment issues in ordinary editor requests
• preserve untitled/notebook handling and watched-file reload behavior for non-file URIs
• keep the workspace service surface synchronous and cover the provider-backed launch path in tests

Why

The goal of this branch is to let PSES honor custom PSProviders for workspace content while still behaving normally for ordinary files. The final shape is intentionally hybrid: provider-backed URIs use PowerShell so custom providers are respected, and file-backed URIs stay on the existing filesystem path to avoid regressions in debugger, symbol, and code lens flows.

This also supports web-based VS Code scenarios where the editor does not share the same filesystem as the language server. In that setup, an extension can contribute a VS Code FileProvider for pspath: while PSES loads a matching PSProvider in its runspace; both sides can point at the same backing persistence mechanism, such as an API, so the client and the language server address the same logical content.

Files changed

• WorkspaceService adds pspath conversion helpers plus provider-backed enumeration/read support
• ScriptFile explicitly recognizes supported URI schemes and treats only true in-memory schemes as untitled
• DidChangeWatchedFilesHandler reloads content through the workspace service and handles non-file URIs more safely
• tests cover provider-backed launch and updated URI classification

Validation

• targeted provider-path unit coverage passes locally
• current PR CI is green on Ubuntu, macOS, and Windows, along with the policy checks

[dkattan]

@andyleejordan Curious your thoughts on this. It ended up being heavier-handed than I wanted with all the async changes, but I'm wondering if that would be desirable if I split it into a separate MR? I know @SeeminglyScience doesn't want me changing the public interfaces, but they likely should've been Task<> from the start, async or not.

[SeeminglyScience]

I know @SeeminglyScience doesn't want me changing the public interfaces, but they likely should've been Task<> from the start, async or not.

Can you talk through what you're trying to solve? When you make a synchronous method return Task<> all you're really doing is requiring wrapper object be created that will be immediately discarded. It doesn't change the behavior at all if that's the assumption.

[dkattan]

Rebased this branch onto the current main and force-pushed feature/get-content at c9425602.

On the sync/async concern: I kept WorkspaceService synchronous and reused the current PsesInternalHost.InvokePSCommand(...) synchronous helpers instead of widening the API surface or asyncifying the workspace methods. The branch now routes file reads / workspace enumeration through PowerShell when a host is available, keeps the existing non-host fallback for current callers/tests, and preserves pspath support for provider-backed documents.

I also added targeted coverage for provider-backed launch (PSProviderPathsLaunchCorrectly) and scheme handling.