Add safe rename, references, and embedded Rhai/CEL editor assistance

[jeremi]

Tracked by #399. Depends on #393.

Outcome

The shared Registry Stack language server moves beyond MVP navigation to safe project-wide refactoring and useful assistance inside authored Rhai and CEL expressions.

Depends on the shared language-server MVP.

Scope

• Find all references for integrations, entities, services, consultation aliases, outputs, claims, credential profiles, and fixtures.
• Prepare and apply safe project-wide rename edits.
• Reject renames that collide, violate identifier constraints, or would produce an invalid project graph.
• Use the generated xw.v1 editor metadata for Rhai helper completion, hover, and signature help.
• Provide context-aware completion for project symbols referenced inside supported CEL and authored expression strings.
• Add targeted quick fixes where the compiler can identify an unambiguous correction.
• Keep expression assistance aligned with the released compiler/runtime ABI rather than a handwritten editor-only function list.

Acceptance criteria

• Find references returns all and only semantic references across a golden project workspace.
• Rename produces a project that passes schema and compiler validation.
• Invalid, ambiguous, or security-sensitive renames are refused with an actionable explanation.
• Rhai xw.v1 completion, hover, and signature help are generated from the same registration catalogue used by Relay.
• CEL completion is limited to symbols actually available in the selected authored context.
• Expression parsing never executes authored code or resolves credentials.
• Regression tests cover flow-style and block-style YAML, quoted scalars, aliases supported by the authoring parser, and multiple project roots.
• VS Code and Zed expose equivalent LSP-backed behavior where each editor supports the protocol capability.

Non-goals

• A general-purpose Rhai or CEL IDE
• Runtime debugging
• Live source inspection

[jeremi]

Review notes, verified against the current tree and prior art (2026-07).

The Rhai premise is stronger than the ticket assumes. The xw.v1 catalogue (XW_V1_FUNCTIONS in crates/registry-relay/src/rhai_worker/xw.rs) is already the same table that registers the helpers at runtime, exposed as machine-readable metadata via registryctl authoring xw --format editor, with a byte-equality regeneration test. The "generated from the same registration catalogue used by Relay" AC is true by construction today; completion, hover, and signature help are mostly presentation work.

Do not plan to reuse rhaiscript/lsp. It is self-described experimental and built for standalone .rhai files, not snippets embedded in YAML strings. At most a reference implementation.

CEL: verify it is actually in scope before budgeting. CEL has zero LSP prior art anywhere (only a syntax-highlighting VS Code extension), so assistance would be built from scratch, ideally on an existing Rust CEL parser (cel-rust / cel-interpreter) rather than a new grammar. But in the current tree CEL appears on the Notary side (type: cel workers), and I could not confirm CEL expressions appear in any of the five authored project file roles. If CEL only lives in generated or deployment config rather than authored YAML, CEL assistance drops out of this ticket entirely. Worth confirming against the Notary consultation surface before this ticket is scoped further.

Rename mechanics: anchor rename edits on the span index from #401 (the same infrastructure as diagnostics), and keep the AC that unsafe renames are refused. The quoted-scalar and flow-style coverage in the AC list is exactly right.