feat(contentmapper): support whole-symbol rename edit projection

Problem

Content Mapper protocol v1 cannot safely rename one semantic symbol when generated and authored spellings differ.

A Vue mapper, for example, needs to project this authored listener:

<Child @save-item="handler" />

to a TypeScript reference to the child's saveItem declaration. A protocol Atom correctly maps the whole generated saveItem span to the whole authored save-item span and works for hover, definition, and references. Rename still fails closed even when the Atom advertises FeatureRename.

At bddd2162710e50281fa838456a875fd59ee7c91f (the Content Mappers PR microsoft/typescript-go#4712 head):

• GetRenameInfo skips every mapped input whose fidelity is not exact.
• getRenameInfoSuccess rejects a non-exact trigger span.
• renameEditRange skips every mapped occurrence whose writeback is not exact.
• the fourslash contract explicitly verifies that Atom origins cannot be renamed.

Changing the projection to verbatim "save-item" is not equivalent: TypeScript then sees a different property symbol, so definition/reference navigation no longer reaches the child saveItem declaration. It also cannot express the required per-occurrence replacement: renaming to semantic nextItem must write next-item in the template and nextItem in the TypeScript-shaped declaration.

Requested design

Please add a safe whole-symbol edit projection mechanism for Content Mappers. Two possible shapes:

1. A mapper RPC that receives the complete rename transaction (semantic replacement plus generated/original spans) and returns validated authored text edits.
2. A declared per-segment edit codec/strategy that can map a semantic replacement in both directions for whole-symbol Atom or Alias segments.

The contract should:

• allow prepare-rename from a single whole-symbol Atom without pretending it has verbatim geometry;
• transform each reference's replacement according to its authored spelling;
• validate bounds, overlap, URI ownership, and document versions before returning one atomic workspace edit;
• fail closed if any required occurrence cannot be projected exactly;
• never return edits targeting generated documents;
• preserve the existing exact-only behavior for ordinary Atom segments without an edit projection;
• clarify whether FeatureRename is valid on Atom segments in protocol v1, since it is currently accepted by validation but cannot make rename succeed.

Acceptance test

Given a child declaration named saveItem and parent usages authored as both @saveItem and @save-item:

• rename from any character of either parent usage updates the child declaration and all parent usages;
• rename from the child declaration updates all parent usages;
• semantic replacement nextItem writes valid camel/kebab spellings at the corresponding sites;
• semantic or authored replacement input with kebab casing has a defined, deterministic normalization policy;
• hover, definition, and references retain their current Atom fidelity;
• no approximate (0, 0) or generated-file edit is returned.

This is not Vue-specific: template languages commonly normalize casing, prefixes, or sigils while keeping one semantic symbol.

Inizia con GetRenameInfo, getRenameInfoSuccess e renameEditRange, quindi leggi il contratto fourslash esistente che verifica che le origini Atom non possano essere rinominate. Confronta le due forme di proiezione proposte con il comportamento di Content Mappers PR e il test di accettazione. Il lavoro è completo quando le modifiche atomiche supportano le occorrenze di Atom o Alias per l’intero simbolo senza modificare i file generati, mantenendo il comportamento exact-only negli altri casi.