Deferred: adopt PostHog tracing at GA (replace the Sentry OTel span bridge)

[JSONbored]

Part of epic #8286 (Phase 4 — Sunset). Deferred — revisit when PostHog tracing reaches GA. Mirrors JSONbored/metagraphed#7768.

Context

loopover's tracing today: src/selfhost/tracing.ts opens one OpenTelemetry span boundary per review-pipeline stage; src/selfhost/otel.ts exports via OTLP when configured, and bridges the same spans to Sentry via SentrySpanProcessor (buildSentryOpenTelemetryBridge) when Sentry is on. The OTLP export path is vendor-independent and is not at stake in this epic — only the Sentry span sink is.

PostHog tracing is not GA. Until it is, the options at Sentry-decommission time are (a) accept OTLP-only (operators/maintainer point OTLP at any backend) or (b) keep a minimal Sentry footprint for spans only. That call is recorded on the decommission issue; THIS issue tracks the eventual real evaluation:

Scope (when unblocked by GA)

• Evaluate PostHog as the trace backend for the loopover-operated fleet: OTLP ingest compatibility with the existing otel.ts export path, span correlation with $exception/$ai_generation events, cost at our span volume.
• If adopted: wire as an OTLP endpoint config (no new SDK), document for self-hosters as one more OTLP-compatible backend choice — never a forced default.

Boundaries

• Nothing here blocks the epic's other phases. Do not start before GA; check status when the Sentry-decommission issue reaches its OTel gate.

[linear-code]

JSO-5745