Add cross-package TypeScript reference support via additional_workspace_folders

[meirLixen]

Closes #750 (partially)
Related to #1260

Summary

• Adds additional_workspace_folders setting in ls_specific_settings["typescript"] to enable cross-package find_referencing_symbols and request_references in monorepos
• Each listed folder is registered as an LSP workspace folder during initialization, and a representative .ts file is opened to trigger tsserver project loading
• Adds _is_cross_workspace_path() / _resolve_file_uri() helpers in the base SolidLanguageServer class to canonicalize URIs for paths with .. segments, applied consistently across all LSP request methods

Configuration

# project.yml or project.local.yml
ls_specific_settings:
  typescript:
    additional_workspace_folders:
      - ../sibling-package
      - /absolute/path/to/other-package

Paths can be absolute or relative to the project root. Results are cached, deduplicated, and validated (non-existent paths are skipped with a warning, paths overlapping with the repo root are ignored).

How it works

1. During TS language server initialization, additional folders are included in the LSP workspaceFolders array
2. After server startup, a representative .ts file from each folder is opened via didOpen to trigger tsserver project loading (tsserver only loads projects on-demand)
3. Files are registered in open_file_buffers with permanent ref_count to stay open for the server lifetime
4. Cross-workspace paths (../other-package/src/file.ts) are resolved to canonical URIs via _resolve_file_uri() to prevent mismatches between tsserver-returned URIs and Serena-computed URIs

Test plan

• test_cross_package_find_references — verifies request_references finds refs across packages
• test_cross_package_referencing_symbols — verifies request_referencing_symbols resolves containing symbols across packages
• test_without_additional_workspace_no_cross_refs — baseline confirming cross-refs don't appear without config
• All 3 existing TypeScript tests pass (no regressions)
• Edge cases handled: non-existent paths, duplicates, overlap with repo root, robust path component .. detection

[MischaPanch]

Thanks for the PR. Is there a reason why we can't do that centrally in the base class, such that it works for all language servers?

[meirLixen]

Good question! The URI normalization (_is_cross_workspace_path / _resolve_file_uri) is already in the base SolidLanguageServer class and works for all language servers.

The TS-specific part is the additional_workspace_folders configuration and the file-opening logic in _open_additional_workspace_files. This is TS-specific because:

1. LSP workspace folder initialization differs per server — each language server subclass builds its own _get_initialize_params(), and not all language servers support multi-root workspaces the same way
2. tsserver requires explicit file opening to load projects — other language servers (e.g. Java/jdtls, Rust/rust-analyzer) may handle project discovery differently
3. The representative file finder (_find_representative_ts_file) looks for .ts/.tsx files near tsconfig.json

That said, moving the workspace folder resolution to the base class (with per-language override hooks for the file-opening strategy) would be a natural next step if other language servers need this. Happy to refactor if you'd prefer that approach.

[MischaPanch]

Yes, pls refactor this to be future proof, even if the implementation will only work for typescript now. Pls change the logic such that the user can always provide the config in a uniform way, so we have a fixed API for users for providing additional workspaces. Then add methods in the base class where needed which raise if this option is not supported/implemented yet, and override the methods accordingly in typescript. Alternatively, you could task an agent with actually implementing and testing it for the most important LS.

You could investigate whether it makes sense to post-process the initialization params and include the workspaces in a default fashion directly in the base class, overriding the default behavior where needed. But I don't know the best way to handle this, so I'll leave proposing the most suitable design to you at this stage - so this is just a suggestion to consider. @opcode81 and might go back to proposing a different structure after your initial proposal, but we don't have time to dive into it ourselves now.

Since this is a significant extension, it should be thoroughly documented in our docs and in the changelog as well. Thanks for laying the groundwork for this!

[MischaPanch]

@meirLixen just FYI - the JetBrains variant of Serena has first-class support for all external dependencies out of the box

[meirLixen]

Refactored as requested in c1a72a7:

• additional_workspace_folders is now a top-level project.yml setting (uniform API for all languages)
• Flows through ProjectConfig → LanguageServerFactory → SolidLSPSettings → SolidLanguageServer
• Base class provides: _resolve_additional_workspace_folders(), _build_workspace_folders_param(), _activate_additional_workspaces()
• Subclasses override _find_representative_source_file() (raises NotImplementedError by default) and optional indexing hooks (_signal_expect_indexing, _wait_for_additional_workspace_indexing)
• TypeScript overrides just these three methods
• Added entry to CHANGELOG.md and documented in project.template.yml

Adding support for another language server would only require overriding _find_representative_source_file() and calling self._build_workspace_folders_param() in _get_initialize_params().