Implement the Registry Stack project language server MVP

[jeremi]

Tracked by #399. Depends on #396 and #401.

Outcome

One shared Registry Stack language server supplies project-aware navigation and editing features to both VS Code and Zed. Editor integrations remain thin clients and do not reimplement the authoring compiler.

Depends on the versioned editor metadata and structured diagnostics contract (#396) and span-preserving authoring YAML parsing (#401).

MVP scope

• Expose a standard-input/standard-output LSP entry point, preferably through registryctl lsp unless a separate binary has a demonstrated packaging advantage.
• Discover a project from its nearest registry-stack.yaml without scanning outside the editor workspace.
• Track open and changed buffers so diagnostics and navigation reflect unsaved content.
• Index authored declarations and references across:
  • project integrations and their file targets;
  • entities and their file targets;
  • services and consultations;
  • integration inputs and outputs;
  • claims and credential-profile claim lists;
  • fixture names and reviewed fixture references.
• Provide:
  • document links and go to definition for authored file paths;
  • go to definition for project-local identifiers and qualified output references;
  • project-aware completion for references;
  • useful hover information;
  • document and workspace symbols;
  • structured diagnostics from the compiler/editor diagnostic contract.
• Coexist with normal YAML syntax support rather than replacing YAML parsing, formatting, or highlighting unnecessarily.

Security and developer-experience invariants

• Treat only reviewed project authoring files as inputs. Do not execute project scripts for completion, hover, or navigation.
• Do not read secret values or resolve secret references.
• Do not perform network requests while analyzing a project.
• Preserve authored-path confinement and bounded-file rules.
• Avoid expensive full builds or fixture execution on every keystroke.
• Give actionable diagnostics when a project or installed CLI version is unsupported.

Acceptance criteria

• The server passes protocol-level tests for initialize, open/change/save, shutdown, and cancellation.
• Editing an unsaved buffer updates relevant diagnostics and definitions.
• File paths, integrations, entities, services, claims, outputs, and fixture references navigate to the correct declaration.
• Completion proposes only identifiers valid in the current project and field context.
• Broken or ambiguous references produce precise diagnostics.
• The server handles multiple project roots in one workspace without leaking symbols between them.
• A fixture workspace proves the same behavior through VS Code and Zed language clients.
• Resource bounds and secret-redaction behavior have automated tests.

Non-goals

• Find references and safe rename
• Deep Rhai or CEL expression analysis
• Editor marketplace publication

[jeremi]

Review notes, verified against the current tree and the 2026 LSP ecosystem.

The registryctl lsp subcommand preference is right, for a harder reason than packaging: the project compiler is private API inside registryctl (the crate is publish = false), so the server has to live in-crate anyway, and a subcommand guarantees schemas, metadata, and compiler come from exactly the binary the user builds with.

Name the framework as an open decision. Original tower-lsp has stalled; the live options are tower-lsp-server (active community fork), async-lsp, and rust-analyzer's lsp-server plus lsp-types. Lean: lsp-server, because the compiler is synchronous, concurrency needs are modest, and it is the most battle-tested foundation; a short spike beats assuming. Whichever is chosen, position-encoding negotiation (LSP 3.17 positionEncoding, UTF-16 default) is left to the implementer; budget tests with non-ASCII YAML values.

State the recompute strategy explicitly to prevent over-engineering: cheap layers (YAML parse, schema and shape validation, reference index) on change with debounce; full compile_project on save only. Authored projects are a handful of bounded files, so full recompute per save is fine; nobody should reach for incremental-computation frameworks here.

Order the AC list into milestones so partial PRs land naturally: (1) lifecycle, diagnostics, and file-path document links; (2) identifier index, go-to-definition, completion; (3) workspace symbols and multi-root.

One AC needs rewording. "A fixture workspace proves the same behavior through VS Code and Zed language clients" is automatable for VS Code (@vscode/test-cli on @vscode/test-electron) but there is no headless Zed extension harness as of mid-2026 (open feature request: zed-industries/zed#41738). Suggest: an automated raw-LSP protocol harness plus VS Code integration tests, and a documented manual smoke checklist for Zed.

Depends on #396 and #401 (span-preserving parsing) for precise diagnostic ranges.