[FEATURE] LSP: Add codeAction support for autofix diagnostics

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

## Feature Request

### Problem

Claude Code's LSP client currently supports a limited set of operations:
goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy,
incomingCalls, outgoingCalls

codeAction is not supported. This means even when an LSP server (e.g., Verible for SystemVerilog) provides auto-fix
capabilities for lint diagnostics, Claude Code cannot invoke them.

### Current Behavior

1. LSP diagnostics are reported correctly (e.g., trailing spaces, naming style violations)
2. Some diagnostics are marked as (fix available), indicating the LSP server provides a code action to fix them
3. Claude has no tool to apply these fixes — it must read the file and manually edit each issue, wasting tokens and time

### Expected Behavior

A new LSP operation codeAction should be available, allowing Claude to:

1. Request available code actions for a given diagnostic/range
2. Apply the fix provided by the LSP server

### Use Case

• Verible (SystemVerilog): 70+ lint rules, many with autofix support
• clangd (C/C++): clang-tidy fixes
• rust-analyzer: suggested fixes
• TypeScript/ESLint: auto-fixable rules

This would significantly reduce token usage and improve efficiency when Claude handles lint warnings.

### Workaround

Currently users must either:

• Let Claude read files and manually edit each warning (expensive in tokens)
• Run external CLI tools like verible-verilog-lint --autofix=inplace via Bash (loses LSP integration)

Neither is ideal.

Proposed Solution

Add a codeAction operation to the LSP tool, with two levels of capability:

#### Level 1: Query available code actions
```typescript
LSP({
operation: "codeAction",
filePath: "module.v",
line: 14,
character: 27
})
// Returns: [{ title: "Remove trailing spaces", kind: "quickfix", isPreferred: true }]

Level 2: Apply code action (preferred)

LSP({
operation: "applyCodeAction",
filePath: "module.v",
line: 14,
character: 27,
actionTitle: "Remove trailing spaces" // or actionIndex: 0
})
// Applies the fix directly to the file

Level 3: Batch apply all auto-fixable diagnostics in a file

LSP({
operation: "applyAllCodeActions",
filePath: "module.v",
kind: "quickfix" // optional filter
})
// Applies all available quickfix actions in the file at once

Level 3 is the most impactful — it would allow Claude to fix all simple lint warnings in one call instead of reading the file and
editing line by line. This is analogous to VS Code's "Fix All" command.

Implementation Notes

• LSP protocol already defines textDocument/codeAction request and workspace/applyEdit
• The client just needs to bridge these to a new tool operation
• workspace/applyEdit capability should be advertised in client capabilities during LSP initialization
• Code actions with isPreferred: true are safe to auto-apply

Add a codeAction operation to the LSP tool, with two levels of capability:

#### Level 1: Query available code actions
```typescript
LSP({
operation: "codeAction",
filePath: "module.v",
line: 14,
character: 27
})
// Returns: [{ title: "Remove trailing spaces", kind: "quickfix", isPreferred: true }]

Level 2: Apply code action (preferred)

LSP({
operation: "applyCodeAction",
filePath: "module.v",
line: 14,
character: 27,
actionTitle: "Remove trailing spaces" // or actionIndex: 0
})
// Applies the fix directly to the file

Level 3: Batch apply all auto-fixable diagnostics in a file

LSP({
operation: "applyAllCodeActions",
filePath: "module.v",
kind: "quickfix" // optional filter
})
// Applies all available quickfix actions in the file at once

Level 3 is the most impactful — it would allow Claude to fix all simple lint warnings in one call instead of reading the file and
editing line by line. This is analogous to VS Code's "Fix All" command.

Implementation Notes

• LSP protocol already defines textDocument/codeAction request and workspace/applyEdit
• The client just needs to bridge these to a new tool operation
• workspace/applyEdit capability should be advertised in client capabilities during LSP initialization
• Code actions with isPreferred: true are safe to auto-apply

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_