F# go-to-definition on a BCL type opens a nonexistent file

Symptom

Go-to-definition on an imported F# type navigates to a path that does not exist.

• DateTime → FilePath = "startup", Line = 0
• List.sum → D:\a\_work\1\s\src\fsharp\src\FSharp.Core\list.fsi (a Microsoft build-server path)

The editor opens a file the user does not have. Members are unaffected: DateTime.UtcNow correctly reaches the decompiled System.DateTime.cs:126.

Root cause

src/sidecars/SharpLsp.Sidecar.FSharp/FSharpSemanticNavigation.fs:154-160 — extractDefinition prefers symbol.DeclarationLocation over FSharpMetadataNavigator.tryResolve. FCS fills DeclarationLocation with rangeStartup for imported entities, so the phantom range wins before the metadata navigator is ever consulted.

A consequence: the FSharpEntity arm at FSharpMetadataNavigator.fs:18 is unreachable dead code.

Fix direction

Consult FSharpMetadataNavigator.tryResolve first for imported symbols, or reject a DeclarationLocation that is rangeStartup / names a file that is not in the workspace, before falling back to it.

Why this matters

CLAUDE.md aim #2 makes F# a first-class citizen. C# go-to-definition decompiles metadata correctly; F# does not for types, so F# is strictly behind here.

Provenance

Found while raising F# sidecar coverage for PR #218 (94.03% → 95.58%). Deliberately not fixed there — adding a failing test would have reddened the coverage gate, and the defect predates that PR.

Start in src/sidecars/SharpLsp.Sidecar.FSharp/FSharpSemanticNavigation.fs at extractDefinition and inspect how it handles imported symbols. Then read FSharpMetadataNavigator.fs, especially the FSharpEntity arm at line 18, and run the existing F# sidecar coverage tests. Done means go-to-definition for imported F# types resolves to available metadata or decompiled source rather than startup or external paths, while member navigation remains working.