Fix CodeLens references to search across project references

[Copilot]

• Understand the issue: CodeLens references only count references within the current project, not across project references
• Create test case to demonstrate the issue (shows 1 reference instead of 2)
• Modify the server's handleCodeLensResolve to use multi-project search mechanism
• Run the test to verify the fix (now shows 2 references as expected)
• Run existing tests to ensure no regressions (all tests pass)
• Address code review feedback: Extract common multi-project search logic into reusable helper
• Final validation: all tests pass, linting passes

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Differences/issues with Code Lens references</issue_title>
<issue_description>### Extension Version

0.20251202.1

VS Code Version

1.107.0-insider

Operating system Version

Windows_NT x64 10.0.26220

Steps to reproduce

1. Open https://github.com/gitkraken/vscode-gitlens/blob/cdf7cd3fc2f9246c10081b0b038b68328981d413/src/webviews/apps/home/home.ts#L61
2. And see that there are 70 references using TS, but 31 using TSGO

Issue

Related to #2145
Seeing differences in the references between TS and TSGO

(Loving that this feature is back tho!)</issue_description>

Comments on the Issue (you are @copilot in this section)

@DanielRosenwasser One reason this might be different is that 5.9 was doing a find-all-references from the client, and that worked across projects. In the server-side implementation in 7.0, we use find-all-references very directly, and that only looks in the current project.

If you request find-all-references, are you seeing 70ish references in 5.9 and 31ish in 7.0?</comment_new>
<comment_new>@DanielRosenwasser
(the other reason it might differ is the way that we support IncludeDeclarations: false, and how that might differ with filtering out the isDefinition property that the Strada codebase has)</comment_new>
<comment_new>@DanielRosenwasser
We probably have to wire up find-all-references in such a way that is similar to how our server requests find-all-references across several projects. It'll be a bit tricky to do this in a clean way. I'm guessing a fourslash test with project references should give a good starting example:

package fourslash_test

import (
	"testing"

	"github.com/microsoft/typescript-go/internal/fourslash"
	"github.com/microsoft/typescript-go/internal/ls/lsutil"
	"github.com/microsoft/typescript-go/internal/testutil"
)

func TestCodeLensOnFunctionAcrossProjects1(t *testing.T) {
	t.Parallel()
	defer testutil.RecoverAndFail(t, "Panic on fourslash test")
	const content = `
// @filename: ./a/tsconfig.json
{
  "compilerOptions": {
	"composite": true,
	"declaration": true,
	"declarationMaps": true,
	"outDir": "./dist",
	"rootDir": "src"
  },
  "include": ["./src"]
}

// @filename: ./a/src/foo.ts
export function aaa() {}
aaa();

// @filename: ./b/tsconfig.json
{
  "compilerOptions": {
	"composite": true,
	"declaration": true,
	"declarationMaps": true,
	"outDir": "./dist",
	"rootDir": "src"
  },
  "references": [{ "path": "../a" }],
  "include": ["./src"]
}

// @filename: ./b/src/bar.ts
import * as foo from '../../a/dist/foo.js';
foo.aaa();
`
	f, done := fourslash.NewFourslash(t, nil /*capabilities*/, content)
	defer done()

	f.VerifyBaselineCodeLens(t, &lsutil.UserPreferences{
		CodeLens: lsutil.CodeLensUserPreferences{
			ReferencesCodeLensEnabled: true,
		},
	})
}

It should start out with a baseline like

// === Code Lenses ===
// === /a/src/foo.ts ===
// export function /*CODELENS: 1 reference*/aaa() {}
// [|aaa|]();
// 

which is missing references from the other project.</comment_new>

• Fixes Differences/issues with Code Lens references #2177

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[DanielRosenwasser]

@copilot I think the better thing to do might actually be to get rid of registerMultiProjectReferenceRequestHandler, and shift more of that work into a common helper that handleReferences and handleRename can do. That way, handleCodeLensResolve can call that directly.

[Copilot]

@copilot I think the better thing to do might actually be to get rid of registerMultiProjectReferenceRequestHandler, and shift more of that work into a common helper that handleReferences and `han...

Refactored the code to extract the multi-project search logic into a reusable multiProjectSearchHelper function. Now handleReferences, handleRename, and handleCodeLensResolve all use this common helper, eliminating ~150 lines of duplication. The change is in commit 4beca99.