OTLP metrics ingestion endpoint

## Summary

Sentry's metrics product does not expose an OTLP endpoint, meaning teams already using OpenTelemetry SDKs cannot send metrics to Sentry without adopting the Sentry SDK. This blocks adoption from a growing segment of customers and prospects who are standardizing on OTel.

## Current behavior

Sentry accepts metrics via its own SDK only. There is no OTLP metrics receiver. Customers using OTel-instrumented stacks must either switch SDKs or go without metrics in Sentry.

## Gap

Multiple enterprise customers have flagged this as a blocker or significant friction point. The absence of OTLP metrics support is being escalated in sales conversations and compared negatively to competitors (Honeycomb, Datadog) that already accept OTLP metrics.

Prior discussion: https://github.com/getsentry/sentry/issues/103487

## Technical constraints and prior analysis

OTLP metrics arrive pre-aggregated from the client and/or collector, which complicates percentile accuracy. The constraint varies by type:

| Metric type | Ingestion viable? | Percentile accuracy | Notes |
|---|---|---|---|
| Counter (Sum) | ✅ | n/a | Count/rate queries work fine |
| Gauge | ✅ | n/a | Last-value semantics; no distribution |
| Histogram | ✅ | ~approximate | Bucket counts allow approximate percentiles |
| ExponentialHistogram | ✅ | ✅ good | Log-scale buckets; designed for this use case |

OTLP `Histogram` and `ExponentialHistogram` types include `count`, `sum`, and bucket data in the payload — population size is not lost. Approximate percentiles from bucket data are feasible; `ExponentialHistogram` provides high precision and is supported by all major OTel SDKs as a configurable export mode.

Counters and gauges do not carry distribution data. Percentile semantics cannot be applied to them — this is a data model constraint, not a solvable transport problem. They can still be ingested as time-series values (rates, last-value).

Reference: https://opentelemetry.io/docs/specs/otel/metrics/data-model

A community-contributed OTel Collector receiver for Sentry is in progress: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/42052

## Options

1. **Native OTLP endpoint in Sentry ingest** — implement an OTLP/HTTP or OTLP/gRPC metrics receiver in Relay. Prefer/require `ExponentialHistogram` for distribution types; accept delta temporality. This is the cleanest path and what competitors have done.

2. **OTel Collector → Sentry exporter** — support via the collector-contrib exporter (PR above). Lower Sentry-side investment but requires customers to deploy and configure a collector, adding operational overhead.

3. **Hybrid** — land the collector exporter first as a fast path; follow with a native endpoint for customers who cannot or will not run a collector.

## Recommendation

Pursue option 1 with option 3 as the sequencing strategy. The collector exporter unblocks existing OTel users quickly; a native endpoint is the long-term zero-friction path. Counter/gauge types should be ingested as time-series; histogram types should prefer `ExponentialHistogram` export mode for accurate percentiles.

Action taken on behalf of David Cramer.

Start by reading the prior discussion in issue #103487 and the linked OpenTelemetry metrics data model. Then inspect Relay's ingestion entry points and the collector-contrib PR to establish the implementation scope; done requires an agreed ingestion approach with coverage for the listed metric types and validation of the resulting semantics.

Written by the indexing model from the issue text.