JDTLS spawns separate process per subproject in Gradle monorepos

[ChrisJamesHassell]

In Gradle monorepos, JDTLS resolves its root to the nearest build.gradle (subproject level) instead of the workspace root (settings.gradle). This causes a separate JDTLS process (~1-3GB each) per subproject.

Additionally, JDTLS creates temp data directories via fs.mkdtemp that are never cleaned up on shutdown, leaking across sessions.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• JDTLS spawns redundant per-module processes in Java monorepos, causing OOM #11368: JDTLS spawns redundant per-module processes in Java monorepos, causing OOM (describes the same separate process issue)
• JDTLS uses ephemeral temp directory for -data and lacks JVM heap configuration, causing repeated full index rebuilds and potential OOM #13070: JDTLS uses ephemeral temp directory for -data and lacks JVM heap configuration, causing repeated full index rebuilds and potential OOM (describes the temp directory cleanup issue)

These issues should be consolidated to avoid duplicate work on the same root cause.

[ChrisJamesHassell]

#12123 (comment)

Fixed