fix: resolve function names from preceding source map token

[vincent861223]

TypeScript's source map generator attaches the original function name to the function keyword token rather than the identifier that follows. When the token at the identifier position has no name, check the immediately preceding token and use its name if it maps to the same original source position.

Detailed Problem Description

Some source map generators (notably Closure Compiler) attach the original
function name to the function keyword token rather than to the identifier
that follows it. When looking up a minified identifier like Uc1bk, the
token at that position has no name, causing the resolver to fall back to
the literal minified name.

This fix checks the immediately preceding token when the current token has
no name. If it maps to the same original source position (same source file,
line, and column), we use its name. This is safe because tokens mapping to
the same original position are part of the same logical mapping, just split
across multiple VLQ segments.

The same-source-position guard ensures we don't incorrectly inherit names
from unrelated tokens (e.g., Foo before prototype in Foo.prototype.bar).

[loewenheim]

Hi, thank you very much for the reproduction and the contribution. Unfortunately this fix is a bit ad-hoc and fragile; as you yourself note, it is currently limited to looking behind one token, and I think lifting that restriction would complicate things quite a bit.

I believe the better way to address the problem is to normalize sourcemaps so that pathological cases like this (multiple mappings to the same original source position, only one of which has a name) are taken care of by construction. We've had an issue open for this in rust-sourcemap for a long time, but saw it more as a nice-to-have; seeing that this causes an actual problem for you, we will re-prioritize it.

[loewenheim]

Also, can you expand on how the sentry-repo fixture was generated? The way the 3 tokens for function a all point to initServer in the original code is highly suspicious and probably unintended. There might be another bug lurking here.

[vincent861223]

Context on how we identified the issue:
We noticed that several source maps uploaded to Sentry contained symbols that weren't being unminified correctly. To investigate, we downloaded the source maps and wrote a script to verify the symbols. Our script confirmed that the symbols exist and point to the correct function definition lines, but they are structured in a way that Sentry fails to recognize the function names.

Regarding the test fixture:
We used Claude to analyze our original source map structure and generate a simplified version that reproduces the bug. We also verified the fix against the original source maps, though we haven't included those larger files in this push.

[loewenheim]

I owe you an apology. This fix is in fact cleaner than what I had in mind. I'll get it merged and deployed as soon as possible.