Scala: give Metals the build roots rather than the repository root

[merlinorg]

Fixes #1766.

Root cause

Metals serves one build per workspace folder — MetalsLanguageServer.initialize makes a Folder per entry of the workspaceFolders it is given and WorkspaceFolders.initServices creates a ProjectMetalsLspService for each. Serena sends exactly one: the repository root, from LanguageServerConfig.workspace_folders (default ["."]) via DefaultInitializeParamsBuilder, which ScalaLanguageServer does not override.

Where the builds live below that root, Metals falls back to its own search, BuildTools.searchForBuildTool — one level down, collectFirst. That is what keeps a single build in a subdirectory working, and it is exactly why a second one cannot: every build but the first is left with no build target and answered by the fallback presentation compiler, so find_referencing_symbols/request_references come back empty with nothing in the logs at Serena's level to say why.

ls_workspace_folders is a real workaround for a pure-Scala repository, and #1766 says so. It runs out in a polyglot one: it is a single project-level list shared by every language server and it also sets what SolidLSP indexes, so once another server needs the repository root as its folder there is no value that suits both.

Fix

ScalaLanguageServer detects the build roots under the repository root and passes them all as workspace folders, one Metals service per build. Detection follows the markers BuildTools probes for — sbt (including a project/build.properties naming an sbt.version with no build.sbt), mill, gradle, maven, scala-cli, Bazel, Deder, and a .bsp/.bloop holding a connection file. It stops descending at a build root, skips build output and dependency directories, follows symlinks as Metals does, and is bounded by depth.

Where the repository root is itself a build root it returns immediately and nothing changes for existing single-root users.

Two settings under ls_specific_settings.scala for where the heuristic guesses wrong: project_roots (an explicit list, relative to the repository root) and project_root_scan_depth (default 3), both validated in the manner of the existing on_stale_lock.

ls_additional_workspace_folders is preserved and appended — those folders can lie outside the repository, so detection could never recover them.

This uses the _create_initialize_params_builder extension point from #1631 as intended; it is the first override of it. The shape is #1444's _find_mix_exs for Elixir, generalised from "first match, one level" to "all of them, bounded depth".

Behaviour change worth knowing

For a repository whose builds are below its root, Metals now writes .metals/ and .bloop/ into each build directory instead of the repository root, and those users get a one-time re-import. The H2 stale-lock check follows, running per build root rather than only at the repository root. Single-root repositories are untouched.

Testing

33 unit tests in test/solidlsp/scala/test_scala_build_roots.py covering detection, the two settings, and the workspace folders that actually reach initialize. None of them need Metals, so they run in CI rather than joining the end-to-end suite #839 is about.

End-to-end, against the reproduction in #1766 — before, beta returns nothing for the full four minutes; after:

workspaceFolders: ['file:///tmp/mono/alpha', 'file:///tmp/mono/beta']
references to alpha.Lib.greet: ['alpha/src/main/scala/alpha/App.scala']
references to beta.Lib.greet: ['beta/src/main/scala/beta/App.scala']

ruff check, ruff format --check, ty check src/serena src/solidlsp and ty check test --exclude test/resources are clean.

Checklist

• This PR follows the guidelines in CONTRIBUTING.md regarding the scope of PRs.
• For changes that add features or fix problems, I have added an entry to CHANGELOG.md, which concisely describes the change.

---

Prepared with the help of Claude Code; I have reviewed and tested the change and will handle review myself.