Relay observability: per-broadcast subscriber/viewer metrics — preferred design?

## Summary I'm building on `moq-relay` and need **per-broadcast subscriber (viewer) counts** for operations — capacity planning, spotting popular vs. idle streams, and alerting. I couldn't find a clean way to get this from the relay today, so before sending a PR I'd like to ask what design you'd prefer. ## What I found (moq-relay 0.10.22 / moq-lite 0.15.15) - The relay has an HTTP server (`/certificate.sha256`, `/announced`, `/fetch`) but **no `/metrics` or stats endpoint**, and `--help` shows no metrics option. - The relay delegates session serving to `moq-lite`, so the **per-subscription lifecycle is only known inside `moq-lite`** (`lite::publisher::recv_subscribe`). The relay itself doesn't see individual track subscriptions. - The relay initializes tracing opaquely (`moq_native::Log`), so a downstream consumer **can't inject a custom `tracing` Layer** to observe the existing `subscribed started` events. - **Log parsing is unreliable**: `subscribed started {broadcast, track}` is logged, but on abrupt disconnects (tab close, network drop) the "leave" is only surfaced after the QUIC idle timeout, and I couldn't find a clean matching "ended" event at INFO — so a `started − ended` count drifts upward and never converges. ## What I prototyped (in a fork) A RAII guard in `lite::publisher::recv_subscribe`: increment a counter when a subscription starts, decrement on `Drop`. Because `Drop` runs on every termination path (complete / cancel / error / connection drop), the count is **accurate even for ungraceful disconnects** (converges within the QUIC idle timeout; immediate on graceful close). It's exposed via a relay `/metrics` (Prometheus `moq_relay_subscriptions_active{broadcast, track}`). This works, but it bakes a `prometheus` dependency + a global registry into `moq-lite`, which isn't great for a core library. ## Question Would you welcome relay observability upstream, and which shape do you prefer? 1. **Feature-gated metrics in `moq-lite`** — `prometheus` behind a `metrics` feature flag. 2. **A generic instrumentation hook / observer trait** on the session/publisher, so consumers wire their own metrics (no `prometheus` in the core lib). 3. **A tracing-based approach** — e.g., expose subscription spans / allow the relay to compose a layer, so a metrics layer can observe `subscribed started/ended` without forking. 4. **Metrics only in `moq-relay`**, fed by a minimal per-subscription hook from `moq-lite`. Happy to send a PR matching whichever direction you prefer. Thanks for the project!