P0-7: Real OpenTelemetry tracing (currently scaffold-only)

Problem

crates/aisix-obs/src/otlp.rs:26-55 reads OTLP config and logs an info line, but does not install the pipeline. Comment lines 43-50 explicitly say "initialisation deferred". OtlpHandle is a marker struct.

Every Datadog / Honeycomb / Tempo / Grafana customer asks for distributed tracing on day 1. We're not even shipping a working OTLP exporter. LiteLLM has 6+ APM-grade integrations.

Scope

DP (moonming/ai-gateway)

• Replace the marker otlp.rs with real `opentelemetry_otlp` + `opentelemetry_sdk` pipeline init: HTTP/gRPC export, batch span processor, resource attributes (service.name, service.version, host.name).
• Instrument the proxy hot path with spans: per-request root span (with model/api_key_id/provider tags), child spans for guardrail / cache / rate-limit / upstream-call. Use tracing-opentelemetry to bridge.
• Sampling config (head-based: parentbased_traceidratio).
• Honor incoming traceparent / tracestate headers (W3C trace context propagation).

CP (api7/api7ee-3-control-plane)

• N/A — DP-only initially. CP can adopt later.

Dashboard UI (api7/AISIX-Cloud)

• Environment Settings page: OTLP config (endpoint, headers, sample rate). Today it'd be in DP config files; if config is centrally managed via etcd, expose it here.

e2e

• Bring up Jaeger / OTel Collector in compose, send a chat completion, assert the trace lands with the expected span tree (request → guardrail → cache → upstream).

Estimate

DP 3d, CP 0d, UI 0.5d, e2e 1d

Start with crates/aisix-obs/src/otlp.rs:26-55 and inspect the proxy hot path plus existing guardrail, cache, rate-limit, and upstream-call entry points. Review the deferred initialization comments and determine how the OTLP pipeline, resource attributes, sampling, and trace context fit the current Rust configuration. Done means exported traces contain the requested span tree and the compose-based Jaeger or OTel Collector check observes it.