TestFindReferencesAsync_UsingAlias fails deterministically on macOS

## Summary

`TestFindReferencesAsync_UsingAlias` fails 100% of the time on macOS (`Test_macOS_Debug_OSX.15.Amd64.Open`). Both `mutatingLspWorkspace: True` and `False` variants fail with the same assertion error. This is not flaky — it reproduces on every CI run.

## Error

```
Assert.True() Failure
Expected: True
Actual: False

at FindAllReferencesHandlerTests.TestFindReferencesAsync_UsingAlias(Boolean mutatingLspWorkspace)
in src/LanguageServer/ProtocolUnitTests/References/FindAllReferencesHandlerTests.cs:line 346
```

## Root Cause

The failing assertion at [line 346](https://github.com/dotnet/roslyn/blob/main/src/LanguageServer/ProtocolUnitTests/References/FindAllReferencesHandlerTests.cs#L346):

```csharp
Assert.True(results[0].Location.DocumentUri.ToString().EndsWith("String.cs"));
```

The test creates a source file with `using MyType = System.String;`, performs Find All References on the alias, and expects:
1. `results[0]` — the metadata definition of `System.String`, with a URI ending in `String.cs`
2. `results[1..2]` — the two source references

On macOS, `results[0].Location.DocumentUri` does not end with `String.cs`. The metadata navigation URI format likely differs on Unix/macOS compared to Windows.

## Affected Builds

This fails consistently on `main` branch CI. Examples (all on `Test_macOS_Debug_OSX.15.Amd64.Open`):

| Build | Helix Job | Result |
|-------|-----------|--------|
| [1380449](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1380449) | `2b820feb-b24d-494b-948c-537843e3fbc3` | Both attempts fail |
| [1379925](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1379925) | — | Both attempts fail |
| [1378782](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1378782) | — | Both attempts fail |
| [1377628](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1377628) | — | Both attempts fail |

## Notes

- AzDO test results show `null` for errorMessage/stackTrace — this is a Helix reporting artifact. The full assertion details are visible in the Helix console logs.
- The test passes on Windows, so the URI scheme or metadata file path convention is platform-dependent.
- The `Assert.True(...)` could be improved with a message parameter to surface the actual URI on failure, which would make future debugging easier.

Start in src/LanguageServer/ProtocolUnitTests/References/FindAllReferencesHandlerTests.cs at line 346 and run TestFindReferencesAsync_UsingAlias for both mutatingLspWorkspace values on macOS. Inspect the actual metadata DocumentUri and compare it with the Windows result. Done means the test correctly handles the platform-dependent URI while still verifying the metadata definition and two source references.

Written by the indexing model from the issue text.