Counters, gauges and histograms for the replikativ stack, with nothing
underneath them.

One process-wide registry — metrics are process-level by nature; scoping
is by label — of named instruments, each a family of series keyed by its
labels:

  (inc!     :konserve_bytes_written_total {:backend :file} 4096)
  (gauge!   :datahike_connections {:database "…"} 3)
  (observe! :datahike_commit_seconds {:database "…"} 0.042)

`snapshot` returns the registry as plain data; `replikativ.metrics.prometheus`
renders it in the exposition format, `replikativ.metrics.konserve/sink`
folds konserve's events into it, and `replikativ.metrics.jvm` samples the
JVM at scrape time. Recording is one `swap!` on an atom: safe from any
thread, cheap, and never throws for a well-formed call.

Names are keywords in Prometheus style (`snake_case`, unit last:
`_seconds`, `_bytes`, `_total` for counters); labels a map of keyword to
keyword, string, number or uuid. `describe!` adds the help text and
histogram buckets a scrape shows; an instrument first seen by a recording
call gets its type from that call and no help.

The JVM's own numbers, sampled at scrape time from the platform MXBeans
under the names micrometer uses — so the stock Grafana JVM dashboards read
a replikativ process without a metrics library underneath.

A `konserve.metrics` sink that folds konserve's events into the registry.
Register it in the process that owns the stores:

  (konserve.metrics/add-sink! ::prometheus replikativ.metrics.konserve/sink)

No dependency on konserve here — only on the event shape it documents:
`{:backend :store-id :op :level :nanos :error :bytes}`.

The Prometheus text exposition format, from a `replikativ.metrics`
snapshot and any extra samples (the JVM's, say). Deterministic: names and
label sets sorted, so two scrapes of the same state are the same text.