Expose sentry-sample_rate from DSC Baggage as a Native Span Attribute for Central Observability & Governance

### Problem Statement

# Context

The Sentry SDK already propagates the effective sampling rate as part of the Dynamic Sampling Context (DSC) via the W3C baggage header (sentry-sample_rate). However, this value is not surfaced as a queryable attribute in Sentry's span data model — meaning platform teams cannot audit or govern sampling configurations across projects without requiring each development team to manually add custom tags in their application code.

## Problem Statement
In large organizations managing dozens or hundreds of Sentry projects, understanding the effective sampling rate applied by each team is critical for:

- **Quota governance** - identifying projects over-consuming span volume
- **Signal quality auditing** - detecting projects with sampling too low (blind spots) or too high (noise)
- **Centralized observability** - building dashboards without depending on per-team instrumentation discipline

Currently, the only way to infer sampling rates is by cross-referencing the Stats page (accepted vs. client-discarded spans), or by asking each team individually. Both approaches are manual, error-prone, and unscalable.

## Proposed Solution

Since `sentry-sample_rate` is already present in the baggage header of every sampled trace envelope received by Sentry's ingest pipeline, we propose that Sentry automatically extract and index this value as a first-class span attribute - for example:

```
sampling.rate → e.g. 0.0001
sampling.mechanism → e.g. "tracesSampleRate" | "tracesSampler" | "parentSampled"This would enable platform/SRE teams to:
```

- Query spans filtered or grouped by `sampling.rate` across all projects
- Build dashboards showing effective sampling distribution per project
- Set alerts when a project's effective sampling rate deviates from expected thresholds
- All of this **without requiring any code changes** from individual development teams

### Why Now / Why This Approach

- The data already exists in the ingest pipeline - this is anextraction problem, not a collection problem
- It aligns with Sentry's direction toward Dynamic Sampling and quota management tooling
- It reduces the governance burden on platform teams in multi-project organizations
- It enables better collaboration between SDK authors and platform owners without friction

### Alternatives Considered

- **Custom tags per team**: Works but requires code discipline across every project and team, which is unreliable at scale.
- **Stats page inference (accepted ÷ total)**: Approximate and not actionable at the span/trace level.
- **Sentry's Dynamic Sampling Rules UI**: Controls server-side sampling but does not expose client-sidetracesSampleRateconfigured in the SDK.

## Requested Outcome
Surface `sentry-sample_rate` (and ideally `sentry-sampled`) from the DSC baggage as indexed, queryable span attributes in Discover, the Spans dataset, and Stats - enabling central platform teams to audit and govern sampling configuration without modifying application code.

### Solution Brainstorm

_No response_

### Product Area

Unknown

Start by tracing how the ingest pipeline handles the DSC baggage header and how span attributes are represented and indexed. Check the Discover, Spans dataset, and Stats paths to determine the required scope. Done means sentry-sample_rate is queryable as a native span attribute across the requested surfaces, with the proposed sampling metadata behavior defined.

Written by the indexing model from the issue text.