swarm-controller: extract jobq_metrics into its own hive-jobq-metrics crate

hive-jobq-metrics/README.md

@@ -0,0 +1,20 @@
+# hive-jobq-metrics
+
+OTEL export of a [`hive-jobq`](../hive-jobq) graph's state rollup, using the
+same [`hive-jobq-wire`](../hive-jobq-wire) `state_rollup()` counts a viewer's
+`/rollup` endpoint would serve — ridden out to the collector on a timer
+instead of only on request.
+
+**Why this is not part of `hive-jobq` or `hive-jobq-wire`.** Both of those
+crates are dependency-light on purpose (no `tokio`, no HTTP client) — the
+scheduler is logic, the wire crate is presentation, and neither wants to drag
+the OTEL SDK, an async runtime, and an OTLP HTTP client into every consumer
+that just wants to run a graph or serialize one to JSON. Metrics export is a
+third concern with its own weight, so it gets its own crate rather than
+bloating either of theirs.
+
+`spawn_exporter` is generic over `hive_jobq::scheduler::Scheduler<N, R>` — any
+host's jobq instance can call it, not just one hardcoded caller. It holds no
+process-global state: call it once per graph you want exported, and keep the
+returned `SdkMeterProvider` alive for as long as export should continue
+(dropping it stops the `PeriodicReader`).