Sentry Backend Modification for SSR Traces

## The Problem: Cached SSR pages have no connected client/server trace
SSR meta-frameworks cache the HTML/render output: a server renders a page once (build-time, first visit, or on revalidation). Later visitors get the stored result from the server (so no server trace or a disconnected one).
Probably thousands of client pageloads map to one server render.

### Differences to previous_trace linking
- `previous_trace` is a 1:1 relationship
- Cached server pages are 1 origin with many consumers (1:N)
- Time-gap between server and client can be as long as the cache lifetime

## What exists
- Span Links Spec: https://develop.sentry.dev/sdk/telemetry/traces/span-links/
- Relay has full support for span links (`sentry.links` and `sentry.link.type`) and passes them through untouched
- Span consumer flattens each span link(s) into a JSON attribute `sentry.links` - stored in EAP
- `sentry.links` is not queryable (`private=True`)
- Span Attribute support for `previous_trace`

## What we need
1. **Span links, queryable in EAP** - indexed by `trace_id` in both directions
- **Prio 1**: One of multiple, different consuming traces (e.g. browser pageload trace) should be able to link to the one connecting server trace
- **Prio 2**: Also nice: One cached server trace should be able to link to all the client/browser traces it served
- What is the cost of this query?
- Can we get an aggregate (e.g. just the number) of it?
2. Workaround (near-term solution): Register a queryable attribute (similar to previous_trace - [here in code](https://github.com/getsentry/sentry/blob/f4df1b22e6a2b5460eb0cfcc5d3d29a6d0b5d3e7/src/sentry/search/eap/spans/attributes.py#L526))
- we only need this workaround if the task above (links in EAP) takes too long
- Only works for N:1 lookup (like Prio 1 task from above)
- Example naming: `simple_sentry_field("cache_origin_trace")`
- Can we do a 1:N lookup with this attribute?
3. Querying Time Window
- Being able to query links within a window that fits cache lifetimes (not assumptions of e.g. 1 hour windows)
- What are possible limitations here?

Start with the Span Links Spec and the referenced sentry/search/eap/spans/attributes.py entry point, then review how Relay and the span consumer pass links into EAP. Done means the project has a decided, queryable approach for linking cached server and client traces, including supported directions and cache-lifetime query windows, or a documented attribute workaround if indexed links are not feasible.

Written by the indexing model from the issue text.