Epic: deferred standalone-editor semantic and UX breadth

## Goal

Complete the deliberately deferred standalone-editor breadth from #1306 without changing SharpTS's VS Code coexistence contract: `sharpts-lsp --language-features full` should become a more complete TypeScript language service, while `interop-only` continues to avoid duplicating ordinary TypeScript features supplied by `tsserver`.

This epic groups work that is not fully parallel:

- safe property/member rename depends on checker-owned member identities and complete definition/reference domains;
- expression/type-node spans enable precise inlay placement and other position-sensitive features;
- semantic tokens, folding ranges, and formatter interoperability can proceed independently once their contracts are fixed.

## Product boundary

The work is primarily for standalone LSP clients. Do not advertise general TypeScript features from `interop-only` unless the specific child establishes a non-conflicting SharpTS-only contract. Feature mode remains fixed at initialization unless dynamic registration is implemented.

A child may remain deferred when measured demand does not justify its cost. Closing a child with a documented no-build/integration decision is acceptable only where its acceptance criteria explicitly define that outcome.

## Planned children and dependencies

- [ ] #1391 — complete expression/type-node span provenance. Foundational for precise position-sensitive features; can run in parallel with checker member identity.
- [ ] #1392 — preserve checker semantic identities for properties/methods. Foundation for member LSP work.
- [ ] #1393 — property/method definition and references. Depends on #1392.
- [ ] #1394 — completeness-gated property/method rename. Depends on #1392 and #1393.
- [ ] #1395 — configurable inlay hints. Depends on the span coverage required from #1391.
- [ ] #1396 — semantic tokens. Parallel; use #1391 only where token spans are insufficient.
- [ ] #1397 — folding ranges. Parallel; use existing spans/delimiters and #1391 only where needed.
- [ ] #1398 — formatter interoperability and decision gate. Parallel; native formatting is not presumed.

```text
#1391 ──> #1395
#1392 ──> #1393 ──> #1394
independent/parallel: #1396, #1397, #1398
```

## Cross-cutting requirements

- Reuse checker/parser truth; do not build a text-matching semantic model alongside the compiler.
- Position math remains half-open UTF-16 and document/version snapshot-consistent.
- Workspace features honor project references, closed files, unsaved buffers, cancellation, cache invalidation, and completeness gating.
- Ambiguous structural member domains return no unsafe edit rather than a partial or guessed result.
- Malformed/incomplete files fail soft and never crash the server.
- New general-language capabilities are advertised in `full` mode only.

## Epic acceptance

- [ ] Every implemented child meets its focused acceptance and verification matrix.
- [ ] Dependency-ordered children are completed in order; parallel children do not introduce hidden coupling.
- [ ] `interop-only` capability and behavior regression tests remain green.
- [ ] `full` initialize handshakes advertise exactly the implemented capabilities.
- [ ] Focused LSP unit/integration tests cover TS, TSX, multi-file modules, project references, unsaved edits, stale versions, cancellation, and malformed source as applicable.
- [ ] `dotnet test tests/SharpTS.Tests/SharpTS.Tests.csproj`, Test262, and TypeScript conformance baselines show no regression.
- [ ] The language-server tool packs successfully, the VS Code extension compiles, and Neovim/Helix documentation reflects the final capability set.
- [ ] Performance measurements are recorded for a representative multi-project workspace; any material parse/check latency or retained-memory regression is explained and accepted.

## Non-goals

- Replacing `tsserver` in SharpTS's default VS Code experience.
- Guessing semantic relationships by matching property text.
- Building a native formatter without first satisfying the formatting-strategy child's decision gate.
- Pulling interpreter debugging into the language server.

Related: #1306.

Start with the dependency graph and the focused child issues #1391–#1398; begin with an unclaimed child rather than implementing the epic as one change. Use the listed LSP, dotnet test, Test262, conformance, packaging, and editor checks as applicable. Done means the selected child’s acceptance criteria pass without changing interop-only behavior or introducing regressions.

Written by the indexing model from the issue text.