Advertise only backed wright-lsp capabilities and declare the LSP support scope

[e54-bot]

Readiness: ready-for-implementation for making declarations truthful. The 1.0 scope question under "Follow-up decision" does not block this issue.

Goal

wright-lsp advertises and reports only language-service behavior that the current implementation actually backs, and Wright's documentation states the supported LSP scope. Editors should not be told that capabilities exist when they always return nothing, and valid documents should not receive error diagnostics.

Context

• wright-lsp declares hoverProvider, definitionProvider, referencesProvider, completionProvider, renameProvider, and semanticTokensProvider in initialize (crates/wright-lsp/src/main.rs).
• In wright-language, hover and definition always return None; references, completion, and semantic_tokens always return empty results; rename always refuses (crates/wright-language/src/service.rs).
• LanguageService::analyze always returns source-provider-unavailable for every document, not only for OPY/DEL. The LSP therefore publishes an error diagnostic even for a valid raw Workshop document (crates/wright-lsp/tests/lsp.rs opens a valid main.ws and only asserts that diagnostics are an array). wright-lsp never negotiates with a source provider.
• Tests currently lock in the unbacked claim: workshop_lsp_workflow_keeps_protocol_and_lifecycle_contracts asserts hoverProvider == true.
• wright-lsp ships in every release archive (scripts/package-release.py), and docs/language-services.md describes the full capability list as an accepted baseline.
• This conflicts with the 1.0 product contract in Roadmap to v1.0: stable Workshop tooling platform #134: public surfaces must be intentionally stable and truthful, and must not claim behavior beyond what the owner implementation supports.

Scope

• initialize advertises only capabilities with a real backing implementation. Today that is document sync.
• No error diagnostic is published for a raw Workshop document merely because no source provider is negotiated.
• OPY/DEL/OSTW documents still receive an explicit source-provider-unavailable diagnostic while no provider language-service capability is negotiated, with no static fallback.
• Requests for capabilities that are not advertised return a well-formed LSP response and never crash the server.
• docs/language-services.md, the README, and any support matrix state the current LSP scope. Architecture text that describes provider-backed capabilities as future work is marked as such.

Non-goals

• Implementing hover, definition, references, completion, rename, or semantic tokens for any language.
• Wiring provider rename or edit validation into the LSP (Wire provider-driven mutation through Wright product surfaces #156).
• Removing wright-lsp from release artifacts. That belongs to the follow-up decision below.
• Changing the editor-neutral wright-language / thin wright-lsp layering.

Follow-up decision (not blocking)

What LSP scope does Wright declare for 1.0?

• A. Diagnostics and lifecycle only, with provider-backed features added as owner capabilities appear (for example Implement LPP rename and edit validation in opy-provider opy-rs#403).
• B. Also ship raw Workshop language services from the canonical workshop-rs program and the existing wright-analyzer SemanticIndex, which already has symbols, references, and spans. Diagnostics would match wright check.

Record the outcome on #134 and open implementation issues only for the chosen scope.

Acceptance criteria

• The initialize result contains no provider entry for hover, definition, references, completion, rename, or semantic tokens. The LSP tests assert that these capabilities are absent.
• Opening a valid raw Workshop document publishes no source-provider-unavailable diagnostic. A test asserts this.
• Opening an .opy document still publishes source-provider-unavailable with no fallback results.
• Sending an unadvertised request, such as textDocument/hover, yields a valid JSON-RPC response (a null result or a method-not-found error, applied consistently) and the server keeps running.
• Review check: docs/language-services.md and the README describe no LSP capability that the current code does not implement.
• Ablation: re-adding hoverProvider: true or restoring the unconditional Workshop diagnostic makes the corresponding test fail.

Dependencies / ownership

• Owner: Wright (wright-language, wright-lsp, docs).
• Related: Roadmap to v1.0: stable Workshop tooling platform #134 (1.0 contract), Wire provider-driven mutation through Wright product surfaces #156 (provider-driven mutation through product surfaces), and Implement LPP rename and edit validation in opy-provider opy-rs#403 (opy-provider rename and edit validation).

[e54-bot]

Decision: LSP scope for 1.0 is B

Owner decision recorded. Wright 1.0 declares raw Workshop language services from the canonical workshop-rs program and the existing wright-analyzer SemanticIndex, in addition to diagnostics and lifecycle. Provider-backed services for OPY and DEL/OSTW remain future work gated on owner capabilities.

Rationale: SemanticIndex already holds symbols, references, and spans, so hover/definition/references for raw Workshop are a real capability, not new analysis. Declaring only diagnostics would understate what the implementation backs — the opposite failure from the one this issue fixes, but the same kind of untruthful declaration.

This does not change this issue's scope. The initialize result must still advertise only what is backed at the time of the change, which today is document sync. Scope B defines what Wright commits to declaring by 1.0, and the implementation issues for it are separate.

Related: #429 promotes the same SemanticIndex-backed query surface to the CLI. The two share one resolution layer in wright-driver/wright-analyzer; neither should grow its own.