tsserver loads files as inferred projects, not the real tsconfig project

[youngwoo-john]

find_referencing_symbols returns 0 for TypeScript while find_symbol/definition work

Preconditions:

find_referencing_symbols / request_references returns 0 references for TypeScript symbols that have many real cross-file callers, while find_symbol, get_symbols_overview, and request_definition all work correctly on the same running server. Python references (pyright) work fine in the same project.

I traced the LSP wire protocol: the references request is well-formed and points at the correct identifier position, tsserver does ~2s of real work, then returns count=0. This appears to be the unresolved TS tail of #478. Diagnosis: tsserver is treating each didOpen'd file as a standalone inferred project and never loads the package's tsconfig.json, so find-references has no project graph to search.
Issue details:

Setup

• Serena: 1.5.3 (latest on PyPI)
• MCP client: Claude Code
• typescript-language-server: 5.1.3; typescript/tsserver: 5.9.3
• Node: v22.20.0; OS: Linux x86_64 (kernel 6.1)
• Language backend: typescript (also reproduced with typescript_vts)
• Project: TS monorepo, no root tsconfig.json — each package owns its own. The target package's tsconfig.json is plain include-based ("include": ["src/**/*.ts", ...]), no composite, with one project references entry to a sibling package. ~21k files total.

Reproduction

Target: an exported const fromNumber in <pkg>/src/util/mathCore.ts, with 76 in-package caller files, all under <pkg>/src/, imported via plain relative paths (import { fromNumber } from '../util/mathCore').

1. Create a SolidLanguageServer (mirroring ls_manager.create_language_server) with repository_root_path = the package root (so its tsconfig is THE project) and additional_workspace_folders=[].
2. request_document_symbols(file) → locate the symbol (works; returns it at line 42, char 13).
3. request_references(file, line=42, column=13) → returns [].

Wire trace (the key evidence)

Request is correct; tsserver returns count=0 after real work:

solidlsp -> ls: {"jsonrpc":"2.0","method":"textDocument/references","id":4,
  "params":{"textDocument":{"uri":"file://.../<pkg>/src/util/mathCore.ts"},
  "position":{"line":42,"character":13},"context":{"includeDeclaration":false}}}
solidlsp.ls perf: request_references path=src/util/mathCore.ts elapsed_ms=2029 count=0

On the same server: request_definition returns a hit, and request_references for a Python symbol returns correct cross-file callers — so the client plumbing is fine; this is specific to the TS server's find-references.

What I tried (all still return 0)

• additional_workspace_folders set to the package roots
• Package opened as the LSP root (its tsconfig primary)
• Pre-opening all 75 caller files via request_document_symbols + a 30s wait
• typescript_vts (vtsls) backend
• serena project index
• Raising INDEXING_PROGRESS_TIMEOUT
• Confirmed neither the symbol nor its callers sit under an ignored dir name (node_modules/dist/build/coverage, re: TypeScript/vtsls language servers hard-ignore any directory named coverage, hiding legitimate source dirs from symbol tools #1523)

Suspected cause + questions

tsserver only returns references for files in a loaded project. When solidlsp didOpens a .ts file it seems to land in an inferred (single-file) project instead of tsserver loading the owning tsconfig.json, so find-references has nothing to search. Definition still works because it follows imports forward.

1. Does solidlsp signal tsserver to load the tsconfig project for an opened file (e.g. _typescript.configurePlugin, openExternalProject, or relying on upward tsconfig.json auto-detection)? On this layout it appears to stay inferred.
2. Is find-references known to require composite/project-references or a specific initializationOptions? Ours is a plain include-based config.
3. Your test_typescript_cross_package fixture passes — how does it differ structurally (composite? root tsconfig?) from a no-root-tsconfig, include-based package?