File links use Windows paths in non-Local multi-root sessions on Remote WSL

- Copilot Chat Extension Version: 0.62.0 (bundled)
- VS Code Version: 1.134.0 (`110a328ea54b42367b803ec53ee0bf52ef26b419`)
- Remote - WSL Extension Version: 0.104.3
- OS Version: Windows 10.0.26200.9106; WSL 2.7.12.0; Ubuntu; Linux kernel 6.18.33.2-microsoft-standard-WSL2
- Feature: File links in session chat responses in a Remote - WSL multi-root workspace
- Selected model: Model-independent; VS Code renders and opens the links

File links produced in a multi-root session that is not Local are converted to Windows-style paths and do not open in a Remote - WSL window. The same kind of link produced in a multi-root session delegated to Local retains forward slashes and opens successfully.

I have not tested single-root sessions, so this report makes no claim about their behavior.

The experimental `chat.agentHost.copilotAgent.multiRootEnabled` setting was enabled because a multi-root session can be delegated to Local only if the setting was already enabled when that session was created. To test the Local behavior, I therefore created a new eligible multi-root session and delegated it to Local, and that solves the problem for new sessions.

Steps to Reproduce / Observed Comparison:

1. Open a multi-root workspace in a Remote - WSL window.
2. In a multi-root session that is not Local, ask the agent to create a file such as `/tmp/example.log` and provide a link to it, or to link an existing workspace file such as `/home/user/project/src/example.ts`.
3. Hover the link. VS Code displays the POSIX path with Windows-style backslashes, for example `\tmp\example.log` or `\home\user\project\src\example.ts`.
4. Click the link. The editor reports that the file was not found and does not open it.
5. For comparison, ensure `chat.agentHost.copilotAgent.multiRootEnabled` is enabled before creating another multi-root session.
6. Create the new multi-root session and delegate it to Local.
7. Repeat the same request in the Local multi-root session.
8. The Local session's link displays forward slashes and opens successfully.

The files exist and open normally from the WSL Explorer or **File > Open File** in both cases.

For the affected non-Local multi-root session, manually providing an explicit remote URI also fails:

```markdown
[example.ts](vscode-remote://wsl+ubuntu/home/user/project/src/example.ts)
```

VS Code serializes the authority as `wsl%2Bubuntu`, then attempts to resolve that URI without a matching filesystem provider. The renderer log records:

```text
[RemoteAgentHostProtocol] Request failed: Resource not found: vscode-remote://wsl%2Bubuntu/home/user/project/src/example.ts
[RemoteAgentHostProtocol] Request failed: Failed to read content: vscode-remote://wsl%2Bubuntu/home/user/project/src/example.ts: ENOPRO: No file system provider found for resource 'vscode-remote://wsl%2Bubuntu/home/user/project/src/example.ts'
Error: The editor could not be opened because the file was not found.
```

Expected:

File links in both Local and non-Local multi-root sessions preserve POSIX separators and open through the current WSL remote filesystem.

Actual:

- Non-Local multi-root session links are displayed as Windows paths and cannot open WSL files.
- Local multi-root session links retain forward slashes and open successfully.
- The broken behavior affects files both inside workspace roots and elsewhere in the WSL filesystem, including `/tmp`.
- Single-root sessions were not tested.

Note about the experimental setting:

`chat.agentHost.copilotAgent.multiRootEnabled` must be enabled before a multi-root session is created for that session to be eligible for delegation to Local. This eligibility requirement is separate from the file-link bug.

Related:

- #293492
- #251076
- #301167