feat(proxy): support multi-level navigation from decompiled JAR classes

[FanXingChunShui]

Summary

When JDTLS resolves a symbol that lives inside a JAR, it returns jdt:// URIs. java-lsp-proxy already rewrites those into temporary decompiled .java files so Zed can open them, but navigation then stopped: Zed sends follow-up requests against the temporary file:// URI, which JDTLS does not understand.

This PR adds the reverse half of that mapping so navigation can continue from one decompiled class into another.

Changes

• proxy-common: add file_uri_to_path (inverse of path_to_file_uri).
• proxy (decompile.rs): persist a file:// -> jdt:// mapping as a <name>.java.jdt-uri sidecar next to each cached decompiled source.
• proxy (main.rs):
  • rewrite incoming textDocument request URIs back from file:// to jdt:// before forwarding to JDTLS;
  • suppress didOpen/didChange/didSave/didClose for decompiled-source worktrees so JDTLS never treats them as editable project files.

The mapping is stored on disk rather than in memory because Zed opens decompiled files in their own worktree, which spawns a fresh java-lsp-proxy process.

Validation

• cargo test -p proxy-common -p java-lsp-proxy: 53 + 11 tests pass (including 5 new tests).
• cargo clippy -p proxy-common -p java-lsp-proxy --all-targets: clean.
• cargo fmt --all: clean.
• cargo check -p gradle-lsp-bridge: passes.
• Manually verified in Zed that follow-up navigation from a decompiled JAR class now works.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: ckwang.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @FanXingChunShui on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[FanXingChunShui]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[tartarughina]

@FanXingChunShui Could you point to a readily available example where the issue you are addressing here exists?
I'd like to try the change myself before approving.

[tartarughina]

Let's please strive to use compile time checks rather than runtime

[FanXingChunShui]

Done in b490a90 — file_uri_to_path now uses #[cfg(windows)] / #[cfg(not(windows))] blocks, so only the branch for the current platform is compiled.

[FanXingChunShui]

@FanXingChunShui Could you point to a readily available example where the issue you are addressing here exists? I'd like to try the change myself before approving.

Any Java project reproduces it — no special dependencies required, the JDK alone is enough, since JDTLS returns jdt:// URIs for any class that lives in a JAR. Steps (with the Java extension built from this PR):

1. Open any Java project in Zed.
2. Go to Definition on a symbol defined in a JAR, e.g. println in System.out.println("hi"). Zed opens the decompiled class from the jdtls_decompiled temp directory — this already worked before this PR.
3. From inside that decompiled class, Go to Definition on another symbol, e.g. a field type or method return type like PrintStream.

Before this PR, step 3 silently does nothing: Zed sends the follow-up request against the temporary file:// URI, which JDTLS does not recognize. This PR maps that URI back to the original jdt:// URI before forwarding, so navigation continues — and it chains, so you can navigate from one decompiled class into the next.