Observability without dependencies: OTel/Prometheus adapters, tracing, histograms

[cognis-digital]

safequeue is deliberately standard-library only — no third-party dependencies. Observability is exposed through a tiny metrics.Recorder interface (Inc/Set/Observe) with a Nop default and an expvar adapter that publishes under /debug/vars. The queue emits enqueued, dequeued, acked, nacked, dead_letter, throttled, rejected, depth, high_water, plus enqueue latency.

The open question is how far to go on observability without compromising the zero-dependency promise.

1. OpenTelemetry.
Anyone can implement Recorder against an OTel meter today, so the queue itself needs no OTel dependency. Options for making it turnkey:

• Ship an OTel adapter in a separate module (.../safequeue/otel with its own go.mod) so the core stays dependency-free and only users who import the adapter pull OTel in. This seems like the cleanest way to have both. Thoughts?
• Or leave OTel entirely to callers and just document the interface. Simpler, less turnkey.

2. Tracing / context propagation.
Observe gives latency but no spans. Should Enqueue/Dequeue accept a context.Context so callers can propagate trace context (message enqueued in span A, processed in span B)? This is a small API addition but touches the hot path.

3. Prometheus.
expvar is stdlib but not Prometheus-native. Would a stdlib-only /metrics text-exposition-format handler (hand-rolled, no client_golang dependency) be valuable, or do people prefer to bridge expvar → Prometheus with an existing exporter?

4. Histogram fidelity.
The expvar adapter reduces Observe to count+sum (average latency only). Is p50/p95/p99 needed at the core, or is that a job for the OTel/Prometheus adapter where real histograms live?

Where's the line for you — is the Recorder interface + expvar enough, and OTel/Prometheus strictly opt-in adapters, or do you want first-class support in-tree?