OpenTelemetry metrics for Fedify HTTP request performance

[dahlia]

Summary

Add request-count and duration metrics for HTTP requests handled by Federation.fetch(). These metrics should expose aggregate request rate, latency, and status-code error rate even when request traces are sampled.

This issue narrows #316 to HTTP request metrics and depends on the meterProvider work in #619.

Current state

Fedify already creates OpenTelemetry server spans for incoming HTTP requests. Those spans record request method, full URL, response status, and response headers.

Those spans help debug individual requests, but sampled traces cannot reliably answer aggregate questions such as request rate, p95 latency, or status-code error rate.

The metrics must avoid high-cardinality attributes. url.full is useful on spans, but it should not become a metric attribute. Use fedify.endpoint for the stable category. Add fedify.route.template only when the matched template is available and contains parameter names, not parameter values.

Proposed solution

Once #619 adds metrics support, register HTTP server metrics around Federation.fetch().

Proposed instruments:

• fedify.http.server.request.count: counter, incremented once per request.
• fedify.http.server.request.duration: histogram, recording request duration in milliseconds.

Proposed attributes:

• http.request.method
• http.response.status_code, when a Response exists
• fedify.endpoint: webfinger, nodeinfo, actor, actor_key, inbox, outbox, object, collection, collection_page, not_found, not_acceptable, or error
• fedify.route.template, when available

Before implementation, decide whether to use OpenTelemetry HTTP server metric names directly or Fedify-prefixed names. Do not mix both naming schemes. Whichever names are chosen, attributes must stay low-cardinality and compatible across releases.

Scope

• Add request count and request duration metrics to @fedify/fedify.
• Use existing router match information where possible, rather than raw URL paths.
• Include WebFinger and NodeInfo requests handled by Federation.fetch().
• Keep framework integration packages out of scope; they already call into Fedify's fetch handler.
• Update docs/manual/opentelemetry.md with the new instruments and cardinality guidance.

Acceptance criteria

• HTTP request metrics are emitted when a meterProvider is configured or when the global meter provider is available.
• Request duration is recorded for successful responses, non-2xx responses, and thrown errors.
• Metric attributes do not include raw URL paths, actor identifiers, object IDs, query strings, or full inbox URLs.
• Shared route templates use parameter names rather than parameter values.
• Tests cover at least a successful request, a 404 response, and an exception path.
• Documentation describes the metric names, units, and attributes.

Open questions

• Should Fedify use standard OpenTelemetry HTTP server metric names directly, or Fedify-prefixed names?
• Should fedify.endpoint distinguish queued inbox handling from immediate inbox handling, or should that stay in ActivityPub-specific metrics?
• What should the exact endpoint taxonomy be for actor keys, collections, collection pages, and custom object dispatchers?