Epic: First-class editor support for Registry Stack project authoring

## Outcome

Registry Stack project YAML has first-class editing support in VS Code and Zed, beginning with a schema-driven 1.0 demo baseline and growing into one shared semantic language server. The editor packages remain thin and do not duplicate the project compiler, security rules, or released Rhai/CEL surface.

## Release plan

### 1.0: useful demo baseline

- [x] #394

The 1.0 scope uses the five existing project-authoring JSON Schemas with the editors' normal YAML language servers. It delivers validation, completion, hover documentation, and outlining without waiting for custom semantic tooling.

### 1.2: shared semantic tooling

- [x] #396
- [x] #401
- [x] #393
- [ ] #395
- [ ] #397
- [ ] #398

## Dependency order

```text
#394 schema-driven baseline (1.0)

#396 structured diagnostics and editor metadata
#401 span-preserving authoring YAML parsing
-> #393 shared Registry Stack language server
-> #395 VS Code extension
-> #397 Zed extension
-> #398 references, safe rename, and embedded Rhai/CEL assistance
```

#396 and #401 can proceed in parallel; #393 depends on both. The VS Code and Zed packaging issues can proceed in parallel once the shared language-server contract and MVP are stable.

## Design constraints

- Use the exact schemas, diagnostics, and expression metadata from the selected Registry Stack or `registryctl` release.
- Do not bind editor behavior to a mutable branch or silently mix incompatible versions.
- Preserve normal YAML editing and avoid claiming unrelated YAML files.
- Keep the compiler's trust-boundary checks, bounded paths, and secret handling intact.
- Do not read secret values, execute project scripts, perform live tests, or make source-registry network requests as a side effect of editing.
- Share semantic behavior through LSP instead of implementing it separately in VS Code and Zed.
- Verify a clean developer journey in both editors, separately from protocol and security tests.

## Success criteria

- [ ] A 1.0 demo project gets useful schema-driven editing in VS Code and Zed through a short deterministic setup.
- [ ] Cross-file paths and project-local references navigate correctly through the shared LSP.
- [ ] Invalid syntax and semantic references produce precise, structured diagnostics.
- [ ] Both editor integrations use the same language server and version compatibility contract.
- [ ] Published extension installation, binary discovery, troubleshooting, and release ownership are documented.
- [ ] Advanced rename and expression support never executes authored code or weakens project validation.

Read the release plan and dependency chain, especially #393, #395, #397, and #398, then inspect the five existing project-authoring JSON Schemas and the normal YAML language-server setup described for 1.0. Done means both VS Code and Zed use the shared, version-compatible tooling with useful editing, precise diagnostics, safe reference navigation, and documented installation and troubleshooting.

Written by the indexing model from the issue text.