Profiler: F# samples in match code lose their source file, splitting hot functions #408

Bug

In the F# CPU profiler, a sample that lands in a match's decision tree loses its source file. F# compiles that code to hidden sequence points, and the engine kept a frame's file only when the frame had a visible line. Each such function therefore splits into a located hot function and an unlocated twin. In FsPricingEngine, 61% of Csv.parseLine's samples went to the twin. The heat map and results panel under-report the function, and its share can fall below the listing threshold.

Evidence

The Windows profiler chunk failed on #406 (run 39364686929). Its failures included:

• "the snapshot already names parseLine in Csv.fs"
• "parseAll: sampled 7.0%, measured 24.6%"
• "shortestPath is hot in Routing.fs"

The same job passed unchanged on the next run, so timing decided the outcome.

Fix

Nimblesite/lspkit#18, fixed by Nimblesite/lspkit#19: such a frame takes its method's nearest visible sequence point. Moving the lspkit submodule pointer brings the fix to SharpLsp.