Fix step-usage CodeLens rendering below the method instead of above the attribute

[clrudolphi]

Summary

Regression found while testing master in VS Code after the #471 performance-fix stack landed: the step-usage CodeLens for a binding now renders after the method declaration instead of above it alongside the built-in "N references" lens.

Root cause: StepCodeLensHandler positions its lens using SourceLocation.SourceFileLine — the method identifier's line for Roslyn-discovered bindings, or a PDB sequence-point line (often a line or more into the method body) for connector-discovered ones. Neither is the attribute's own line. A separate, AST-backfilled AttributeSourceLine already exists on ProjectStepDefinitionBinding and is used elsewhere (BindingLocationMatcher, RenameBindingResolver, CSharpAttributeLiteralResolver), but this handler never adopted it.

This was masked as long as every .cs didOpen always re-ran the Roslyn parser (whose method-identifier line reads close enough to "right"). Item 7 in #478 started skipping that redundant reparse once the connector had already succeeded — a genuine performance win — but the side effect is that the registry now keeps the connector's less precise PDB-derived location instead, and the imprecision that was always latent in the connector path became visible.

Fix

Prefer binding.AttributeSourceLine when known (both discovery paths backfill it), falling back to the existing SourceFileLine/Column for the rare case where the backfill itself failed. Also fixes a stale doc comment claiming AttributeSourceLine is always null for connector-discovered bindings — it's been backfilled via a Roslyn re-parse in ConnectorDiscoveryService for a while.

Test plan

• New regression test: Handle_prefers_AttributeSourceLine_over_the_method_identifier_or_PDB_line
• dotnet build — 0 warnings, 0 errors
• Reqnroll.IdeSupport.LSP.Server.Tests — 831 passed (830 baseline + 1 new)
• Reqnroll.IdeSupport.LSP.Core.Tests — 658 passed
• Reqnroll.IdeSupport.LSP.Server.Specs — 165 passed
• Live verification in VS Code — outstanding

🤖 Generated with Claude Code

[clrudolphi]

Update: the attribute-line fix (first commit) rendered correctly in Visual Studio but one line too high in VS Code, per live feedback — VS Code's CodeLens always renders as a floating row above its anchor line, while VS apparently overlays it on the target line directly. Anchoring on the attribute's own line therefore works for VS but overshoots by one line in VS Code.

Pushed a second commit that takes the more robust route: instead of picking a different anchor line to work around each client's rendering convention, it fixes the actual imprecision at the source. SourceLocation.SourceFileLine is the conventional CodeLens anchor (the method declaration's own line — same as the built-in C# references lens every client already renders this way for) and was already precise for Roslyn-discovered bindings; it was only ever imprecise for connector-discovered ones, whose wire-format location is a raw PDB sequence point that can land inside the method body. ConnectorDiscoveryService now backfills the exact AST-based method-identifier location for those too, matching what Roslyn discovery already does — so StepCodeLensHandler goes back to anchoring on SourceFileLine directly, precise for both paths now, and consistent with client CodeLens conventions instead of fighting them.

All three test suites green: LSP.Core.Tests 660, LSP.Server.Tests 830, LSP.Server.Specs 147.