Source code linking doesn't work for span code.filepath when code mappings were derived from error stack frames

## Problem

The Insights span detail view (trace waterfall, DB query source) shows file paths and line numbers via `code.filepath` and `code.lineno` span attributes, and has UI infrastructure to link these to source code (`StackTraceMiniFrame` → `SourceCodeIntegrationLink` → `useStacktraceLink`). However, this link silently fails to render for .NET projects (and likely other platforms) because of a path format mismatch between error stack frames and span attributes.

## Root Cause

The .NET SDK sends different path formats for errors vs. spans:

| Source | Field | Example |
|---|---|---|
| Error frame | `filename` | `DailyDownloadWorker.cs` (bare filename) |
| Error frame | `abs_path` | `/_/src/NuGetTrends.Scheduler/DailyDownloadWorker.cs` |
| Span attribute | `code.filepath` | `src/NuGetTrends.Scheduler/DailyDownloadWorker.cs` |

Auto-generated code mappings (via `auto_source_code_config`) are derived from error event in-app stack frames. For .NET, this means the `stack_root` is derived from the `/_/`-prefixed `abs_path` or the bare `filename`.

When the `/projects/{org}/{project}/stacktrace-link/` API is called for a span with `file=src/NuGetTrends.Scheduler/DailyDownloadWorker.cs`, `convert_stacktrace_frame_path_to_source_path` checks if the path starts with `stack_root`. Since the span's `code.filepath` has neither the `/_/` prefix nor is a bare filename, no code mapping matches, and the function returns `None` (`stack_root_mismatch`). There's no fallback because spans don't provide `absPath`.

Additionally, .NET error frames work around this entirely via `source_link` — a direct URL embedded by the SDK from PDB SourceLink metadata. The frontend (`stacktraceLink.tsx`) has special C# handling that uses `frame.sourceLink` directly, **bypassing code mappings**. This means .NET users may never configure or fix code mappings since error linking "just works" — but span linking silently doesn't.

## Impact

No link to source from queries [such as this](https://nugettrends.sentry.io/organizations/nugettrends/dashboard/193598/?globalFilter=%7B%22dataset%22%3A%22spans%22%2C%22tag%22%3A%7B%22key%22%3A%22sentry.normalized_description%22%2C%22name%22%3A%22sentry.normalized_description%22%2C%22kind%22%3A%22tag%22%7D%2C%22value%22%3A%22sentry.normalized_description%3A%5C%22SELECT%20..%20FROM%20trending_packages_snapshot%20WHERE%20week%20%3D%20%28SELECT%20max%28week%29%20FROM%20trending_packages_snapshot%29%20ORDER%20BY%20growth_rate%20DESC%20LIMIT%20%7Blimit%25s%7D%5C%22%22%2C%22isTemporary%22%3Atrue%7D&project=1266317&release=&statsPeriod=30d)

Users with .NET projects (and potentially other platforms with similar path format differences) see file path + line number in:
- Trace waterfall span details (DB query source)
- Insights module query summaries
- HTTP span descriptions

But the "Open this line in GitHub" link never appears, even though code mappings exist and the GitHub integration is fully configured.

## Possible Solutions

1. **Improve path matching in `convert_stacktrace_frame_path_to_source_path`**: When the exact `stack_root` prefix match fails, try suffix/substring matching — similar to what `auto_source_code_config` already does when *creating* mappings (`_is_potential_match` uses suffix matching). The resolution logic should be at least as flexible as the derivation logic.

2. **Generate code mappings from span data too**: Currently `auto_source_code_config` only processes error events. It could also be triggered by spans that have `code.filepath`, which would create mappings with `stack_root` values that match span path formats.

3. **Leverage `source_link` to derive span-compatible mappings**: When processing error events that have both `source_link` (direct GitHub URL) and `abs_path`/`filename`, Sentry could derive the relationship between the `/_/`-prefixed error path and the repo-relative path (visible in the URL). This mapping would also cover the span `code.filepath` format.

4. **SDK-side: emit `code.source_link` on spans**: The .NET SDK already has SourceLink metadata available. It could also emit a direct source URL as a span attribute, and the `StackTraceMiniFrame` frontend component could use it directly (like `stacktraceLink.tsx` does for error frames).

## Reproduction

1. Set up a .NET project with GitHub integration and SourceLink enabled
2. Trigger errors — stack trace linking works via `source_link` (no code mappings needed)
3. Trigger DB spans with `code.filepath` attributes
4. Open a trace, click a DB span — file path and line show, but no GitHub link

**Live example ([nugettrends.sentry.io](https://nugettrends.sentry.io)):**

- [Trace with DB span showing `code.filepath` but no source link](https://nugettrends.sentry.io/insights/summary/trace/2a515b7615624708abd688666eaa1c49/?node=span-351d239e75a2b8e6&project=1266316&query=&referrer=performance-transaction-summary&source=performance_transaction_summary&statsPeriod=1h×tamp=1770579575&transaction=trending-packages-snapshot-refresh&unselectedSeries=p100%28%29%2Cavg%28%29) — span shows `src/NuGetTrends.Scheduler/DailyDownloadWorker.cs` with no GitHub link
- [Existing auto-generated code mappings](https://nugettrends.sentry.io/settings/integrations/github/162668/?tab=codeMappings) — mappings exist but were derived from error frame paths
- [Span data in Explore](https://nugettrends.sentry.io/explore/traces/?query=has%3Acode.filepath&project=1266316&field=code.filepath&field=code.function&field=db.system&field=span.op&field=span.description&field=platform&field=timestamp&sort=-timestamp&statsPeriod=24h&table=span) — shows spans with `code.filepath: src/NuGetTrends.Scheduler/DailyDownloadWorker.cs` and `platform: csharp`
- Error frames for comparison use `abs_path` with `/_/` prefix (e.g., `/_/src/NuGetTrends.Scheduler/DailyDownloadWorker.cs`) and bare `filename` (e.g., `DailyDownloadWorker.cs`)

## Technical References

- `StackTraceMiniFrame` + `SourceCodeIntegrationLink`: [`stackTraceMiniFrame.tsx`](https://github.com/getsentry/sentry/blob/master/static/app/views/insights/database/components/stackTraceMiniFrame.tsx)
- Path resolution: [`code_mapping.py` `convert_stacktrace_frame_path_to_source_path()`](https://github.com/getsentry/sentry/blob/master/src/sentry/issues/auto_source_code_config/code_mapping.py)
- C# `source_link` bypass: [`stacktraceLink.tsx` L85-91, L175-191](https://github.com/getsentry/sentry/blob/master/static/app/components/events/interfaces/frame/stacktraceLink.tsx)
- Auto mapping derivation: [`auto_source_code_config/task.py`](https://github.com/getsentry/sentry/blob/master/src/sentry/issues/auto_source_code_config/task.py)
- Stacktrace link API: [`project_stacktrace_link.py`](https://github.com/getsentry/sentry/blob/master/src/sentry/issues/endpoints/project_stacktrace_link.py)

Relates to:
* https://github.com/getsentry/sentry-dotnet/issues/3227

Note the SDK is not sending the data out of the box yet ^
[The NuGet Trends code base](https://github.com/dotnet/nuget-trends/blob/52887543a457a3936cc49127df165a03087abc62/src/NuGetTrends.Data/TelemetryHelpers.cs#L47-L50) is doing that directly, using the SDK.

Start with convert_stacktrace_frame_path_to_source_path in src/sentry/issues/auto_source_code_config/code_mapping.py and compare its path handling with auto_source_code_config/task.py. Trace the stacktrace-link API through project_stacktrace_link.py and the frontend StackTraceMiniFrame and SourceCodeIntegrationLink components. Done means spans with repo-relative code.filepath values can produce a source link when matching code mappings exist, with regression coverage for the reported .NET path formats.

Written by the indexing model from the issue text.