12.5 Observability and SLOs for the hosted API #919

Labels: type:ops area:apps-web
Milestone: Wave 2.4 - Hosted registry
Effort: Medium
Depends on: 12.1

Description

packages/pulse-webhooks already ships OtelWebhookMetrics and
PrometheusWebhookMetrics, so the repo has an established metrics idiom.

"Serving reads in production" is only claimable with evidence. Without
instrumentation there is no way to state uptime, latency, or cache hit rate.

Acceptance criteria

• Request count, latency histogram, cache hit ratio, chain-read count and fallback rate are emitted following the existing Otel/Prometheus pattern
• A resolution is traced end to end (API → cache → chain) with the spec hash as a span attribute
• docs/slo.md defines availability, p95 latency and freshness-in-ledgers targets
• An uptime probe hits /v1/registry/health and its history is public
• Every fallback emits a structured log line

Implementation notes

1. Mirror packages/pulse-webhooks/src/OtelWebhookMetrics.ts so operators have
   one metrics vocabulary across the project.

Affected files

• apps/web/app/api/registry/
• packages/pulse-webhooks/src/OtelWebhookMetrics.ts (pattern reference)
• docs/slo.md (new)