Define and enforce Neva CLI, LSP and extension compatibility

[emil14]

Problem

The extension now consumes a separately installed system neva-lsp, so the runtime contract has three independently released components: VS Code extension, neva-lsp, and the Neva CLI used for ▶ Run. A missing or mismatched tool must produce an actionable error rather than an unreliable editor session.

Prerequisite

nevalang/neva-tools#19 introduces neva-lsp version --json and must ship in an LSP component release first.

Scope

• Define the machine-readable compatibility fields: LSP component version, embedded Neva API version, and LSP protocol contract version.
• Make each extension release declare its supported LSP and Neva CLI versions.
• On activation, inspect neva tool lsp version --json; distinguish missing tool, malformed metadata, older tool, and unsupported newer tool.
• Keep neva.lsp.path as an explicit manual/offline override, but validate it by the same contract.
• Verify the Neva CLI only where required (▶ Run); do not invent a runtime CLI dependency for pure language-server features.
• Offer an actionable Install/Update path without re-bundling server binaries into the VSIX.

Definition of done

• Compatibility policy is documented and tested.
• Supported tools start silently.
• Unsupported/missing tools do not start the LSP and explain the exact remedial action.
• The VSIX remains free of neva-lsp binaries.