[M14 language services] Converge LSP rename on the shared semantic refactoring contract

[Teakowa]

Parent: #127
Depends on: #128, #129

Goal

Make Wright's language-service/LSP rename path a thin adapter over the shared M14 semantic rename and validated edit transaction contracts, removing duplicate mutation semantics while preserving the accepted M10 editor behavior.

Context

M10 established project-wide OPY rename and correct multi-document WorkspaceEdit behavior before the M14 source-edit transaction architecture existed. #128/#129 provide the reusable project-aware validation and semantic rename contracts that should now own refactoring semantics.

This issue is a convergence/integration task, not a new editor feature milestone.

Scope

• Route editor-neutral language-service rename through [M14 refactoring] Unify semantic rename across OPY and OSTW on validated edit transactions #129 and its [M14 foundation] Make source-edit transactions project- and frontend-aware #128 validated transaction result.
• Map the shared multi-source transaction to LSP WorkspaceEdit without re-resolving symbols or reimplementing collision/stale checks in the protocol layer.
• Preserve document versions, URI/path mapping, UTF-16 ranges, open overlays, cross-file edits, and stale-version refusal established by M10.
• Extend the LSP rename path to OSTW only where [M14 refactoring] Unify semantic rename across OPY and OSTW on validated edit transactions #129 declares semantic rename supported; otherwise return an explicit unsupported result.
• Keep compiler/session/refactoring contracts free of LSP protocol types.
• Remove or reduce obsolete duplicate rename/edit-validation code only where the shared contract fully replaces it.
• Add protocol-level regressions for OPY and supported OSTW rename, including multi-file overlays, non-ASCII/UTF-16 positions, collisions, and stale documents.

Non-goals

• New LSP features, code actions, formatting, inlay hints, or editor UX.
• LSP-owned semantic rename logic.
• Expanding source-language compatibility.
• Whole-source regeneration.
• Agent/tool-service mutation exposure; tracked separately.

Acceptance criteria

• LSP rename delegates semantic target resolution/edit generation/validation to the shared [M14 refactoring] Unify semantic rename across OPY and OSTW on validated edit transactions #129/[M14 foundation] Make source-edit transactions project- and frontend-aware #128 contracts.
• Existing accepted M10 OPY rename behavior remains intact, including multi-document WorkspaceEdit, overlays, URI/path, UTF-16, and version semantics.
• Supported OSTW rename can be surfaced through the same adapter without an OSTW-specific LSP refactoring engine.
• Unsupported rename targets fail explicitly rather than falling back to textual replacement.
• No duplicate protocol-layer collision/stale/semantic ownership remains where the shared contract provides it.
• Compiler/refactoring core imports no LSP types.
• Protocol and current full CI regressions are green.

Relationships

• Language-service convergence lane under [M14] Validated source edits and semantic refactoring across Wright frontends #127.
• Depends on [M14 foundation] Make source-edit transactions project- and frontend-aware #128/[M14 refactoring] Unify semantic rename across OPY and OSTW on validated edit transactions #129.
• May proceed in parallel with [M14 agent tooling] Expose validated source-edit preview and semantic rename through the shared tool API #130 once [M14 refactoring] Unify semantic rename across OPY and OSTW on validated edit transactions #129 is stable.
• Reuses M10 [M10 correctness] Implement project-wide semantic rename #73/[M10 correctness] Harden LSP URI, UTF-16, and document lifecycle boundaries #74 behavior rather than reopening M10 feature scope.