[建议 / Feature] Implement runtime LSP client — execute `lspServers` for Go-to-definition, hover, diagnostics, and references

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复提议 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

工具调用 / MCP · Tool use / MCP

涉及的 Agent 框架 · Agent framework

不涉及框架 · Not framework-specific

使用场景 · Use case

ZCode parses lspServers in plugin/config schemas and displays an "LSP servers" label in Plugin Settings — but the field is classified as diagnosticOnly and is never executed. No runtime LSP client exists in either the CLI bundle (zcode.cjs) or the desktop app (app.asar).

Verified in v3.3.6:

• lspServers — ✅ parsed in config schema, appears in plugin component lists
• "LSP" — ⚠️ listed in orderProviderVisibleToolContracts Set, but no tool definition exists
• vscode-languageserver* / vscode-languageclient / vscode-jsonrpc — 0 occurrences in CLI
• textDocument/* protocol methods — 0 occurrences in CLI
• LanguageClient / startLsp / createLsp — 0 occurrences in CLI
• All 747 JS files in desktop out/ (main + host + renderer) — 0 occurrences
• vscode-languageserver-protocol@3.17.5 in app.asar — only bundled inside mermaid.js, unrelated

What's frustrating:
Without LSP runtime, the agent is blind to real-time type errors, go-to-definition, find-references, hover documentation, and semantic completion. It falls back to regex grep for navigation — inaccurate and slow. Most language servers (pyright, typescript-language-server, clangd, rust-analyzer) speak LSP, not MCP, so there is no way to leverage them.

建议方案 · Proposal

Implement a runtime LSP client so configured lspServers actually run, exposing language intelligence to the agent.

Phase 1 — MVP (single server, diagnostics):

• LSP client runtime in CLI (zcode.cjs), stdio transport
• Spawn servers from lspServers config
• Expose LSP tool (already reserved in tool list):
  • diagnostics — textDocument/publishDiagnostics for a file
  • definition — textDocument/definition at position
• Document sync via didOpen / didChange / didClose

Phase 2 — Full language intelligence:

• textDocument/hover, textDocument/references, textDocument/completion
• workspace/symbol
• Multi-server support (one per language)
• Auto-detection: pyright, gopls, typescript-language-server, clangd

Phase 3 — Desktop integration:

• Connect renderer to LSP client via existing IPC
• Inline diagnostics, hover tooltips in code views
• Config UI for lspServers (field already has a UI label)

预期价值 · Expected value

• Parity with competitors. Claude Code (shared architecture) supports lspServers natively. Cursor, Copilot, Windsurf, and Continue all use LSP for code intelligence.
• Language coverage. Most languages are LSP-only (Python, TypeScript, Rust, C++, Java). Only a few have native MCP servers.
• Agent accuracy. Go-to-definition and find-references via LSP instead of regex grep = fewer hallucinated locations, faster navigation.
• Plugin ecosystem. The plugin protocol already recognizes lspServers as a component type — making it executable would let plugins provide language servers immediately.

你认为的优先级 · Your perceived priority

高 · High

你使用的 ZCode 版本 / 环境 · ZCode version / environment

v3.3.6 / Linux x64

补充材料 · Additional context

Investigated via bundle analysis of zcode.cjs (9.2MB, 2926 lines) + app.asar (188MB, 21,565 files).

ROADMAP.md sections are currently all TBD — would love to see LSP tracked there.

Start by reviewing the reported bundle findings in zcode.cjs and app.asar, then locate the existing lspServers schema, reserved LSP tool entry, and related plugin settings. Define the Phase 1 boundary and verify that completion includes a working stdio client, server startup, document synchronization, diagnostics, and definition support; record the larger phases in ROADMAP.md.