feat(telemetry): shared metrics vocabulary + operator reconcile emitter

[glageju]

Why

Every Stacklok component today invents its own metric vocabulary — one calls the upstream server mcp_server, another server; one histogram is in seconds, the next in milliseconds; success-vs-failure is a label here and two separate metric names there. The result: you can't write a single cross-component dashboard or alert without memorizing five schemes, and a rename in one repo silently breaks a join in another.

This is the foundational PR of the Metrics Standardization RFC (D6/D8). It puts the shared vocabulary in toolhive-core — one place that defines the label spellings, the histogram bucket shapes, and the emitter-ownership attributes — so every downstream component spells the same concept the same way. Nothing here emits a metric; it's vocabulary plus construction helpers that everyone imports.

What it adds

One package: telemetry/metrics.

• 7 canonical label keys (LabelMCPServer, LabelOutcome, LabelMCPMethod, …) and 3 outcome values (success/error/rejected), so outcome rides on a label instead of splitting into _succeed/_failed metric names.
• 3 histogram bucket presets — BucketsFastHTTP(), BucketsMCPProxy(), BucketsLongRunning() — returned as fresh slices so callers can't alias a shared one.
• D8 emitter-ownership: the stacklok.component / stacklok.product resource-attribute keys, plus the frozen product value stacklok-platform. The per-component stacklok.component value is supplied by each component — core names the concept, not the roster of apps that consume it.
• RegisterBuildInfo(...) + the fleet-wide stacklok.build_info gauge for build/release correlation.

How downstream uses it

A proxy or gateway builds its own instrument with a shared preset and label key — no meter comes from this package:

meter := otel.Meter("stacklok.toolhive.proxy")
hist, _ := meter.Float64Histogram(
    "stacklok.toolhive.proxy.request.duration",
    metric.WithExplicitBucketBoundaries(metrics.BucketsFastHTTP()...),
)
hist.Record(ctx, elapsed, metric.WithAttributes(
    attribute.String(metrics.LabelOutcome, metrics.OutcomeSuccess),
))

Ownership attributes go on the OTel resource once at startup; the component value is the caller's own:

resource.NewWithAttributes(semconv.SchemaURL,
    attribute.String(metrics.AttrStacklokComponent, "toolhive"),
    attribute.String(metrics.AttrStacklokProduct, metrics.ProductStacklokPlatform),
)

Design decisions worth a reviewer's eye

• No Meter(), no metric-name constants. The caller owns its meter and passes a preset's boundaries; this package registers no global state and pins no instrument names.
• Two-or-more-emitter rule. Only concepts ≥2 components emit live here. Single-emitter keys stay with their owner.
• Keys, not per-app values. Core exports the ownership attribute keys, not the concrete component strings — a foundational library shouldn't enumerate its consumers. The one exception is ProductStacklokPlatform: every component must emit that identical string or the fleet-wide stacklok_product selector breaks, so it's a single cross-cutting contract rather than a per-app value.
• stacklok.product frozen at stacklok-platform. Deliberately not stacklok-enterprise — the value lands in customer dashboards and must survive the enterprise→platform rename without churn.
• Resource attribute vs metric label. Ownership attrs are set once on the provider and promoted to labels by the Prometheus exporter, not stamped per instrument.

Tests

The package is guarded by pin tests that fail loudly on a silent respelling — the whole point of the shared vocabulary is that these strings don't drift. They pin every bucket boundary set, label key, outcome value, ownership key, and the frozen product value; plus build_info name/unit and RegisterBuildInfo behavior (validation + the empty→unknown fallback, scraped from a real in-memory OTel reader).

Also in this PR

google.golang.org/grpc bumped 1.82.0 → 1.82.1 to clear a High-severity advisory (GHSA-hrxh-6v49-42gf) the Grype scan flagged — a pre-existing indirect dep, not introduced here, but it rides into the release tag downstream will pin.

Not in this PR

The operator reconcile emitter (D12) was split out on review. It's operator-shared vocabulary, not universal, so its placement — raw toolhive-core vs a shared-operator library — is an open D12 question tracked separately rather than settled here.

Merge order

This must merge and cut a release tag first. toolhive, toolhive-registry-server, and stacklok-enterprise-platform all import this vocabulary and can't build standalone until they bump their toolhive-core pin to the release carrying it.

Links

• RFC: Stacklok Platform Metrics Standardization (D6, D8)