LSP Java (jdtls) on Windows: position-based ops return "No language server available" while workspaceSymbol works

Environment:

- Copilot CLI: 1.0.64
- OS: Windows 11
- Java: OpenJDK Temurin 21.0.9
- LSP server: Eclipse JDT LS (jdtls), launcher org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar
- Project: Spring Boot 3 / Java 17 Maven (medium size)

Config (~/.copilot/lsp-config.json):

{
"lspServers": {
"java": {
"command": "java",
"args": [
"-Declipse.application=org.eclipse.jdt.ls.core.id1",
"-Dosgi.bundles.defaultStartLevel=4",
"-Declipse.product=org.eclipse.jdt.ls.core.product",
"-Dlog.level=ALL",
"-Xmx1G",
"-jar", "C:\\tools\\jdtls\\plugins\\org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar",
"-configuration", "C:\\tools\\jdtls\\config_win",
"-data", "C:\\tools\\jdtls\\workspace"
],
"fileExtensions": { "java": "java" },
"initializationTimeoutMs": 300000,
"warmupTimeoutMs": 300000,
"requestTimeoutMs": 120000,
"spawnTimeoutMs": 60000
}
}
}

What works:

- /lsp test java succeeds; jdtls process spawns and stays alive (~1 GB RSS).
- lsp workspaceSymbol returns correct results with package/line/column after initial indexing (~3 min on first call).

What fails:
All position-based and file-based LSP operations return "No language server available for file" even though the server is healthy and workspaceSymbol works in the same session:

- lsp documentSymbol on a .java file in the project → "No language server available"
- lsp goToDefinition (line/character on a known symbol) → "No language server available"
- lsp findReferences → same
- lsp hover → same
- lsp goToImplementation → same

Tried both Windows paths (C:\...\File.java) and POSIX-style (C:/.../File.java) — same result. The file definitely exists and is inside the project root.

Logs (relevant excerpts from ~/.copilot/logs/process-*.log):

[ERROR] LSP java server for C:\...\gpron-service: workspaceSymbols failed: Request 'workspace/symbol' timed out after 90000ms.

(Resolved after increasing requestTimeoutMs; workspaceSymbol then succeeded.)

Subsequent file-based operations log no jdtls error — the bridge seems to reject the request before it reaches the server.

Suspected cause:

- Possible URI canonicalization mismatch on Windows (file:///c:/... vs file:///C:/...)
- Possible missing textDocument/didOpen notification before position-based requests (jdtls requires the document to be opened first)

Expected: Position-based LSP ops should work consistently with workspaceSymbol once jdtls is initialized.

Workaround: Currently relying on workspaceSymbol + grep for code navigation in Java projects on Windows.

Start by reproducing the Windows behavior with the supplied lsp-config.json, /lsp test java, and a documentSymbol request, then inspect the relevant process-*.log entries. Compare the bridge handling of file-based requests with the working workspaceSymbol request, including Windows URI and document-open behavior. Done means documentSymbol and the listed position-based operations reach jdtls and work for project Java files.

Written by the indexing model from the issue text.