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

Nadie ha tomado este issue todavía.

## 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:

```vue

```

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.

Comienza con GetRenameInfo, getRenameInfoSuccess y renameEditRange; después, lee el contrato existente de fourslash que verifica que los orígenes de Atom no se pueden renombrar. Compara las dos formas de proyección propuestas con el comportamiento de Content Mappers PR y la prueba de aceptación. Se considera terminado cuando las ediciones atómicas admiten ocurrencias de Atom o Alias de símbolo completo sin editar archivos generados, manteniendo el comportamiento exact-only en los demás casos.

Escrito por el modelo de indexación a partir del texto del issue.