Expose additional LSP operations: diagnostics, codeAction, rename

Feature Request

The built-in LSP tool currently exposes 9 operations:

goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls

These are excellent for code navigation, but the LSP protocol has ~40+ capabilities, and several high-value ones are missing. Adding them would significantly improve Claude's ability to understand, validate, and refactor code — especially in typed languages like Java, TypeScript, C#, and Rust.

Requested Operations (by impact)

1. textDocument/diagnostic (pull diagnostics)

Why: Lets Claude check if code compiles and see errors/warnings without running a full build. Currently, the only way to know if a change broke something is to run mvn compile or equivalent — which is slow and noisy. Diagnostics from the LSP are instant since the server is already analyzing the code in the background.

Use case: After editing a Java file, Claude could immediately check "did I break anything?" without a build round-trip.

2. textDocument/codeAction

Why: LSP code actions are context-aware fixes and refactorings: auto-fix imports, implement interface methods, extract variable/method, convert to lambda, etc. These are operations Claude currently does manually (and sometimes gets wrong — e.g., guessing import paths instead of letting the language server resolve them).

Use case: Claude edits a file, a diagnostic shows a missing import → code action resolves the correct fully-qualified import automatically.

3. textDocument/rename

Why: LSP rename is semantic — it understands type hierarchies, updates imports, handles overrides, and renames across the entire workspace. Currently Claude has to use Grep-based find-and-replace, which is fragile (can miss references, rename unrelated symbols with the same name, or break imports).

Use case: Renaming a method on an interface correctly propagates to all implementing classes and call sites.

4. textDocument/signatureHelp (lower priority)

Why: Shows exact parameter types and documentation for a method call. Useful when Claude is writing a call to an API it hasn't read yet.

5. textDocument/typeDefinition (lower priority)

Why: Navigates from a variable to its type declaration (vs goToDefinition which goes to the variable's definition). Useful for understanding what type a variable holds without hovering.

Context

• These operations are language-agnostic — they'd benefit all LSP-enabled plugins (Java/jdtls, TypeScript, Python/pyright, Go/gopls, Rust/rust-analyzer, etc.)
• The LSP server is already running and maintaining full project state — these capabilities are "free" to expose since the server already computes them
• ENABLE_LSP_TOOL=1 suggests the tool is still maturing, so this seems like a natural next step

Environment

• Claude Code CLI (latest)
• Using jdtls-lsp plugin (Eclipse JDT.LS 1.57.0)