fix(metrics): bind meter to our provider directly, bypass single-call global

[pavanputhra]

Summary

Follow-up to #178. The fork-safe init landed, but observed peak `conserver.vcons.inflight` was still 128 across 4 worker processes — same as before — and `host.name` / `service.instance.id` were missing from `resource_attrs` in the metrics backend.

Root cause

OpenTelemetry Python's `metrics.set_meter_provider()` is single-call. When `opentelemetry-instrumentation` (auto-instrumentation) is active in the process, it registers a default MeterProvider early in startup, before this module's lazy `_init_otel_metrics()` runs. Our subsequent `set_meter_provider(our_provider)` is silently ignored, and `metrics.get_meter(name)` returns the global proxy bound to the auto-instrumentation's provider — whose resource we don't control.

The dead giveaway in the ClickHouse `resource_attrs` was `telemetry.auto.version: 0.59b0` — that key is only set by the auto-instrumentation distro's MeterProvider, not by any provider we'd create.

Fix

Bind `meter` to OUR provider directly via `provider.get_meter(name)`, never touching the global. Auto-instrumentation metrics continue to flow through their own pipeline; our application metrics flow through ours. Both end up at the collector independently with their own resource attributes.

Diff

```diff

• metrics.set_meter_provider(provider)
• meter = metrics.get_meter(name)

• meter = provider.get_meter(name)
  ```

Tests updated to assert `set_meter_provider` is NOT called and `meter` is bound to the provider's own meter.

Test plan

• 24 tests pass locally (the fork-safe + inflight + queue_metrics suites)
• After deploy: distinct `resource_attrs` per worker (`host.name` + `service.instance.id` populated). `conserver.vcons.inflight` peak should reach ~512 (2 pods × 2 workers × 128) when the transcribe queue is deep enough.

🤖 Generated with Claude Code