Go To Definition (and span-based tooling) on Razor ~/ asset paths needs source mapping

## Context

PR dotnet/roslyn#84796 adds compile-time `~/` asset-path expansion for Razor components: a literal like `` is rewritten by `ComponentTildePathPass` into a synthetic `Assets[@"images/logo.png"]` C# expression. The synthetic `CSharpIntermediateToken` is emitted with `source: null` -- it deliberately has no mapping back to the `.razor` source.

## Problem

Razor tooling supports **Go To Definition on file paths in string literals** (dotnet/razor#12323). That feature won't work for `~/` asset paths as-is, because:

- The expanded token isn't source-mapped, so tooling can't relate the generated `Assets["..."]` back to the original `~/...` literal span.
- Even an enhanced line pragma can't cleanly map a *substring* of the original literal: the leading `~/` is trimmed during expansion, so the generated key (`images/logo.png`) is not span-identical to the source text (`~/images/logo.png`).

## Follow-up

Investigate how to preserve a usable mapping (or provide an alternative resolution path) so Go To Definition -- and other span-based tooling -- works on `~/` asset paths. This likely needs coordination with the asset-path IntelliSense/completion work tracked in #84793.

Raised from review feedback on #84796.

Start by reading PR dotnet/roslyn#84796 and tracing ComponentTildePathPass through the synthetic CSharpIntermediateToken with source: null. Compare the mapping needs described in dotnet/razor#12323 and the coordination noted in #84793. Done means Go To Definition and other span-based tooling can resolve ~/ asset paths to their original Razor literal or an equivalent usable span.

Written by the indexing model from the issue text.