Publish the Registry Stack extension for Zed

[jeremi]

Tracked by #399. Depends on #394 and #393.

Outcome

Zed users can install a Registry Stack extension that attaches the shared project language server to Registry Stack YAML while retaining Zed's native YAML support.

Depends on the schema-driven baseline and shared Registry Stack language server.

Requirements

• Register and launch the shared Registry Stack language server for the applicable YAML language.
• Preserve Zed's native YAML grammar, formatting, and yaml-language-server features.
• Activate project intelligence only within a detected Registry Stack project.
• Discover a compatible installed registryctl or language-server binary in accordance with Zed extension packaging rules.
• Provide an actionable status/error message for a missing binary or incompatible version.
• Support project-local settings without machine-specific committed paths.
• Publish through the Zed extension registry after local development-extension verification.

Acceptance criteria

• Installing the extension in a clean supported Zed environment enables schema-driven editing and project navigation for a sample project.
• Normal YAML behavior remains available and unrelated YAML workspaces are unaffected.
• Language-server startup, restart, missing binary, and version mismatch paths are tested.
• Project-local schema settings and language-server settings do not require absolute paths.
• The extension performs no implicit live test, credential read, or network access during project analysis.
• macOS and supported Linux installation paths are documented and smoke-tested.
• Publication metadata, licensing, ownership, and release steps are documented.

Non-goals

• Reimplementing authoring semantics in the Zed extension
• Shipping a divergent Zed-only language server
• Replacing Zed's YAML grammar or formatter

[jeremi]

Review notes, verified against Zed docs and shipped extensions (2026-07).

Registration mechanism confirmed. extension.toml [language_servers.<id>] with languages = ["YAML"] runs alongside Zed's built-in yaml-language-server (the Biome extension is a live example of attaching a server to built-in languages). Two packaging notes: extension repositories must carry a license (required since 2025-10), and zed_extension_api has no changelog discipline upstream (zed-industries/zed#52144), so pin wasm_api_version deliberately and treat bumps as tested changes.

"First server wins" for definitions and rename. Zed merges completions and hover across servers and merges pushed diagnostics, but go-to-definition and rename are answered by the first server in language_servers priority order, even if it answers empty (zed-industries/zed#24100; confidence medium, single maintainer discussion). Add an AC that the shipped configuration orders the Registry Stack server ahead of yaml-language-server, and that definitions work in that configuration while yaml-language-server schema validation still shows.

Testing ACs need rewording. There is no headless or automated Zed extension harness as of mid-2026 (open feature request: zed-industries/zed#41738). Startup, restart, missing-binary, and version-mismatch coverage should be automated at the LSP-protocol and binary-discovery layer, with a documented manual smoke checklist for the Zed wiring itself.

Also note the relative-path asymmetry tracked on #394: Zed resolves ./ schema paths from the worktree root, while vscode-yaml resolves them from the YAML file's location.