Fix BFS loop during config lookup

[gabritto]

We were doing an infinite BFS in the project collection builder while looking for a tsconfig for a given file. The loop happened because the BFS node type included a pointer to a logger, which changed every time we computed the neighbors of a node, and so no node was ever considered as already visited, even if we had already visited its corresponding tsconfig.

[Copilot]

Pull Request Overview

This PR fixes an infinite loop bug in the breadth-first search (BFS) used during TypeScript config file lookup. The issue occurred because the searchNode type included a logger pointer that was different for each node computation, preventing the visited node tracking from working correctly.

Key changes:

• Separated the node identity from the logger by introducing a searchNodeKey type containing only the essential fields (configFileName and loadKind)
• Updated the BFS algorithm to use a generic approach with separate key and node types
• Added a regression test to verify that project lookup terminates properly

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/core/bfs.go	Modified BFS algorithm to support separate key and node types, preventing identity issues with varying logger pointers
internal/core/bfs_test.go	Updated tests to use the new BFS signature with explicit key types and added Key() method to test node type
internal/project/projectcollectionbuilder.go	Introduced searchNodeKey type and updated BFS calls to use the new signature for proper node deduplication
internal/project/projectcollection.go	Updated BFS call signature to match new generic parameters
internal/project/project.go	Added Key() method to Project type for BFS compatibility
internal/project/projectcollectionbuilder_test.go	Added regression test with circular project references to verify termination

[jakebailey]

Seems fine to me?