LSP: add completeness-gated property and method rename

Parent epic: #1390. Depends on #1392 and #1393. Deferred from #1306.

## Goal

Add safe property/method `prepareRename` and `rename` only when SharpTS can prove that the complete semantic member domain and complete affected workspace are loaded. Never produce a partial structural rename.

## Safety contract

Rename is stricter than references. A member can have useful definition/reference results while still being unsafe to rename. Ambiguous structural compatibility, dynamic access, external declarations, an incomplete project graph, or an unmodeled occurrence must make `prepareRename`/`rename` return no edit with an explainable reason in logs/telemetry-safe diagnostics.

## Work

- [ ] Define rename-domain rules for private members, nominal class members, overrides/base declarations, static/instance facets, accessors, overloads, interface merging/extension, contextual object literals, and structural record/interface uses.
- [ ] Start with domains whose completeness can be proven (private and nominal members are expected first); explicitly enumerate deferred/refused domains.
- [ ] Reuse #1393 reference results plus declaration facets, but add a completeness audit for every project/config/reference root that can contribute compatible member uses.
- [ ] Handle shorthand properties and destructuring correctly: rename only the property side unless lexical binding identity requires a coordinated edit.
- [ ] Validate new property names for identifier, string-literal, numeric, private-name, and computed-name contexts; refuse a rename that would require syntax-shape conversion unless that conversion is implemented and tested.
- [ ] Preserve getter/setter/overload sets and intentional override relationships; do not merge unrelated same-spelling structural properties.
- [ ] Produce deterministic non-overlapping `WorkspaceEdit` changes for open and closed files using the selected document snapshots.
- [ ] Reject edits when versions are stale or files change during analysis; use document-versioned edits when supported by the protocol model.
- [ ] Keep rename unadvertised/unserved in `interop-only` mode.
- [ ] Document supported/refused member rename cases for standalone clients.

## Verification

- [ ] Positive tests cover private fields/methods, public fields/methods, static members, getters/setters, overloads, inheritance/overrides, generic bases, merged interfaces, contextual object literals, imports/re-exports, and cross-project references for every domain claimed supported.
- [ ] Shorthand/destructuring tests verify property and lexical tokens receive exactly the intended edits.
- [ ] Negative tests prove no edit for unrelated same-spelling properties, ambiguous unions/intersections, `any`, dynamic index access, computed expressions, CLR/built-in members without editable source, malformed configs, missing project references, unreadable files, and incomplete workspace roots.
- [ ] Identifier validation covers keywords, Unicode identifiers, private names, quoted/numeric names, and names requiring escaping or syntax conversion.
- [ ] Workspace edits are sorted, deduplicated, non-overlapping, and round-trip through applying the edits followed by a fresh parse/type-check.
- [ ] A mutation/race test changes a document between analysis and edit production and verifies stale edits are refused.
- [ ] End-to-end JSON-RPC tests cover `prepareRename` plus `rename` across at least two projects and a closed reverse importer.
- [ ] Existing lexical rename completeness gates remain green.
- [ ] Full unit, language-server pack, extension compile, Test262, and TypeScript conformance validation is green.

## Success criteria

Member rename is available only for explicitly supported domains, every returned edit contains all known declarations and occurrences across the complete workspace, applying it leaves the project parseable and semantically bound to the renamed identities, and all incomplete/ambiguous domains reliably refuse the operation.

## Non-goals

- Textual search-and-replace.
- Renaming dynamic runtime properties.
- Claiming complete structural rename until the checker can prove it.

Start with the LSP prepareRename and rename entry points, then review the reference results from #1393 and dependencies #1392 and #1393. Map which member domains can prove complete before implementing support. Done means supported cases produce complete deterministic WorkspaceEdits, while incomplete or ambiguous cases refuse edits and the listed positive, negative, race, JSON-RPC, and full validation tests pass.

Written by the indexing model from the issue text.