Merge branch 'pratik/otel-phase8-log-correlation' into pratik/otel-phase9-metric-gap-fill

Resolved OpenTelemetryPlan/09-data-collection-reference.md: both sides
document the same new metrics, reached by different routes. The incoming
sections came from the phase-6 edit merged forward; this branch already
documents the same surface in its own layout, with the job lifecycle
metrics and the GetObject request path under the MetricsRegistry
section rather than a separate 2a.

Kept this branch's sections to avoid duplicate entries for every metric.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

OpenTelemetryPlan/09-data-collection-reference.md

@@ -70,6 +70,12 @@ There are three independent telemetry pipelines entering a single **OTel Collect
 2. **beast::insight OTel Metrics** (**B**) — System-level gauges, counters, and histograms exported natively via OTLP/HTTP (:4318) to the same **OTLP Receiver**. These are batched and exported to Prometheus alongside span-derived metrics. The StatsD UDP transport has been replaced by native OTLP; `server=statsd` remains available as a fallback.
 3. **MetricsRegistry OTel SDK Metrics** (**C**) — Counters, histograms, and observable gauges registered directly with the OTel Metrics SDK, exported via OTLP/HTTP (:4318). This pipeline owns its own `MeterProvider` and reader, separate from **B**'s, so its export cadence is independent — see [§2.5](#25-per-job-type-queue-gauges) for why that matters when comparing the two.
 
+A third, narrower metrics path exists for instruments created at their call site through the
+`XRPL_METRIC_*` macros. These use the OTel Metrics SDK directly and reach the collector's OTLP
+receiver rather than the StatsD receiver, so their names carry no `xrpld_` prefix. See
+[§2a](#2a-call-site-otel-metrics-metricsregistry). Code in `libxrpl` cannot use these macros and
+always goes through `beast::insight` instead.
+
 **Trace backend** — The collector exports traces via OTLP/gRPC to:
 
 - **Grafana Tempo** — Preferred trace backend. Supports TraceQL queries at `:3200`, S3/GCS object storage for cost-effective long-term trace retention, and integrates natively with Grafana.