Match a path-mapped file name against the solution, not the current directory

[xperiandri]

Go To Definition, Find All References and Rename on a symbol whose assembly was built with a path map
— DeterministicSourcePaths, or a <PathMap> set in Directory.Build.props — open generated
metadata instead of the symbol's source.

Why

A path-mapped assembly names each source file relative to the map's root, and does not record the
root. TryGetDocumentIdFromFSharpRange and FSharpSymbolUse.GetSymbolScope resolved that name with
Path.GetFullPath, that is, against Environment.CurrentDirectory. The current directory belongs to
the process, not to the solution, and holds whatever the last component to set it left there; the
path it produced named a file that does not exist, no document matched, and the symbol was taken for
an external one.

This is the editor half of the path-map fix. #20518 stops the compiler naming the directory twice in
GetDeclarationLocation, which is what reaches the editor in the first place; #20470 keeps the map out
of the options the IDE builds, which covers references between projects held in memory. A referenced
assembly on disk was built by MSBuild with the map, and still carries the mapped names.

The change

Solution.GetDocumentIdsWithFSharpFileName answers which documents a compiler range's file name
denotes:

• a rooted name goes through the workspace's index, as before, so nothing changes for a build without
  a map;
• a relative name is matched by its tail against the paths the solution's documents already have,
  anchored on a separator so that it matches whole directories and never the tail of one. The rule is
  isTheFileAt, which also accepts the doubled separator the compiler writes when the map's
  replacement ends in one (.\ + \src\…).

TryGetDocumentIdFromFSharpRange — Go To Definition, and the declaration document Find All
References starts from, through TryGetDocumentFromFSharpRange — and GetSymbolScope, which decides
the projects Find All References and Rename search, now go through it.

The scan over the solution's documents runs only for a relative name, which means only for a symbol
declared in a path-mapped assembly, and once per navigation: the ranges of the references found are
the solution's own and rooted. Paths are compared case-insensitively; they are not identifiers.

Tests: the rule, including that a name inside a segment matches nothing; and a range whose name a map
left relative finding its document. On the branch this was developed on, running them without the
change fails the second with no document is named by .\Library_…\FileLibrary.fs. On this branch
PathMapNavigationTests pass (9), as do the Go To Definition (3) and Find References (7) tests.

Two lookups in other pending work resolve the same kind of name and need the same rule:
GetSolutionDocumentsWithFilePath in #20462, and the comparison FindSymbolDeclarationInDocument
makes in #20492. Whichever of those merges after this will route through the helper.

Base

Stacked on #20470, which adds PathMapNavigationTests.fs; the diff shrinks to its own commit once
that merges.

🤖 Generated with Claude Code

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes IDE symbol navigation behavior.

Generated by PR Tooling Safety Check · gpt56 1.4M · ◷