MicrowavepropWeb.Telemetry's :telemetry_poller fires
dispatch_oban_queue_depth/0 every 30 s. In test env it runs outside
any Ecto sandbox owner, so its `Repo.all` against oban_jobs holds a
pool connection long enough to starve LiveView `render_async` tests
with 100 ms async windows — repro'd as flaky SkewtLive failures.
Same shape as the PromEx Oban plugin we already disable in test via
:prom_ex_include_oban_plugin. Add :start_telemetry_poller (defaults
to true) and toggle it off in config/test.exs. Production keeps the
30-second per-(queue,state) gauge.
Three small wins from a telemetry audit:
1. Propagation.scores_at/3 wrapped every call in Instrument.span, firing
two handler dispatches that dominated the ~10µs ETS lookup on cache
hits. The map's LiveView fires this on every pan + point-click, so
hot-path latency was mostly telemetry. Span now wraps only the miss
branch (where disk IO makes the duration signal meaningful); hit path
still emits the cheap hit/miss counter the cache-ratio panel reads.
2. Oban queue-depth poller: 10s → 30s. Every replica independently
GROUP-BYs oban_jobs, so each extra replica paid ~3 redundant queries
per minute for a gauge that moves on the hour-scale anyway.
3. Dropped summary(phoenix.endpoint.start.system_time): summarizing a
wall-clock timestamp produces no useful aggregate — stop.duration
below it is the meaningful signal.
