[BUG] LSP goToDefinition/goToImplementation return nothing for all binary-library symbols (JDK + jars); client doesn't handle jdt:// URIs

Preflight

• Searched existing issues — this continues #38453, which was auto-closed as stale (not_planned) without resolution and is still reproducible on the current version.

What's Wrong?

Through Claude Code's LSP tool with the official jdtls-lsp plugin, goToDefinition and goToImplementation return "No definition found. This may occur if the cursor is not on a symbol, or if the definition is in an external library not indexed by the LSP server" for every symbol defined in a binary (kind="lib") classpath entry — including the JDK itself (java.lang.String, java.util.List), not just third-party jars.

On the same symbols, in the same session:

• hover works (full type info + Javadoc, read from attached source)
• findReferences works
• goToDefinition on workspace-local symbols works

So the language server has fully indexed these libraries; navigation specifically is broken.

Root Cause

For any symbol in a binary library entry, jdtls (NavigateToDefinitionHandler → JDTUtils.toUri(IClassFile)) returns a jdt://contents/... URI rather than a file:// URI. That code path is gated on the client advertising extendedClientCapabilities.classFileContentsSupport = true at initialize; if absent, toUri returns null and the handler yields no location. Claude Code's LSP client appears not to advertise this capability and/or not to resolve jdt:// results by issuing the java/classFileContents request. VS Code (redhat.java) and nvim-jdtls do both, which is why navigation works there. The decompiler (FernFlower) is already bundled in jdtls — the gap is purely client-side. This matches #38453.

Expected

goToDefinition/goToImplementation on a library symbol should return the attached/decompiled source in a read-only jdt://-backed buffer, as in VS Code.

Impact

Java users get no dependency-API navigation at all (not even JDK). In Amazon Brazil workspaces — where the entire cross-package dependency closure is kind="lib" jars with source attached — hover is the only working cross-package navigation primitive.

Secondary: misleading error string

The "...not indexed by the LSP server" message is inaccurate for this case — the library is indexed (hover proves it); the cause is the missing client capability. Suggest rewording to e.g. "the language server returned a non-file (jdt://) location that this client cannot open" so it doesn't misdirect debugging.

Repro

1. Any Java project + jdtls-lsp plugin.
2. LSP hover on a java.util.List reference → works.
3. LSP goToDefinition on the same List → "No definition found."
4. Same contrast for any jar-dependency class.

Environment

• Claude Code LSP tool + jdtls-lsp@claude-plugins-official
• jdtls 1.58.0 (Homebrew), macOS (arm64), Java 21
• Related: #38453 (closed stale, unresolved)