Recognise a mapped name as the file a document holds

Finding the document a range names got the caret to the right file, and then the
search for the declaration inside it compared the range's file name to the
document's path with `=`. Under a path map the first is relative to a root the
assembly never records and the second is absolute, so they never match: the
search fell through to a full check of the file, looking for uses of a symbol
that belongs to another compilation, and came back with nothing.

Both places now go through one rule, `isTheFileAt`, rather than two spellings of
it, so a name a path map left relative is matched by its tail wherever a file is
identified.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: xperiandri

vsintegration/src/FSharp.Editor/Navigation/GoToDefinition.fs

@@ -355,7 +355,7 @@ type internal GoToDefinition(metadataAsSource: FSharpMetadataAsSourceService) =
             let! ct = Async.CancellationToken |> liftAsync
 
             match targetSymbolUse.Symbol.DeclarationLocation with
-            | Some decl when decl.FileName = filePath -> return decl
+            | Some decl when decl.FileName |> isTheFileAt filePath -> return decl
             | _ ->
                 let! _, checkFileResults =
                     document.GetFSharpParseAndCheckResultsAsync("FindSymbolDeclarationInDocument")

vsintegration/tests/FSharp.Editor.Tests/PathMapNavigationTests.fs

@@ -66,6 +66,7 @@ let ``goto definition into a project built with a path map reaches its source``
     | ValueSome(FSharpGoToDefinitionResult.NavigableItem item, _) -> Assert.Equal(library.GetFilePath "Library", item.Document.FilePath)
     | result -> failwith $"expected a navigable item, got %A{result}"
 
+/// The one rule the document lookup and the search for a declaration inside a document both go through.
 /// A mapped name arrives with the separator its replacement doubled (`.\` + `\rest`), which is what the
 /// compiler writes and what a build on a path map hands back.
 [<Theory>]