feat(telemetry): expose a native prometheus scrape endpoint

[utsab345]

Description

Implements The-PR-Agent#3191: an opt-in native Prometheus scrape endpoint for the OpenTelemetry command telemetry.

Telemetry stays disabled by default and the exporter is only active when OTEL.EXPORTER_TYPE = "prometheus" — nothing is exposed or changed out of the box. In that mode the pr_agent.commands counter (and any future gauge instruments) is rendered as GET /metrics on the gunicorn-served webhook apps: github_app, gitlab_webhook, azuredevops_server_webhook, and gitea_app.

Gunicorn runs with preload_app = True, so counters must aggregate correctly across workers. The exporter translates each worker's DELTA aggregates into prometheus_client metrics on the worker side, writes them to per-pid state files under a shared PROMETHEUS_MULTIPROC_DIR, and /metrics merges every worker's file with a MultiProcessCollector at scrape time. gunicorn provisions the state directory in when_ready (before the first fork) and deregisters workers in child_exit, so counters stay accurate through worker churn.

1. Dependency change (flagged as requested). This PR adds prometheus-client==0.21.1 to the base dependency set and no other runtime dependency.
2. Why not opentelemetry-exporter-prometheus? The maintainer's suggested approach named that package, but its PrometheusMetricReader documents no multiprocessing support, and the only published versions are 0.x pre-releases. Since multiprocess aggregation under gunicorn is the core requirement of the issue, expecting a MetricExporter to plug into the existing PeriodicExportingMetricReader (my earlier suggestion in the issue comments was based on an inaccurate assumption about that package), I implemented a small in-house bridge on prometheus_client directly. It is ~120 lines, metric-naming and label rules match the OpenMetrics format, and it reuses the existing PeriodicExportingMetricReader + push-on-release flow. Happy to revisit if maintainers prefer a different dependency strategy.
3. The endpoint is mounted only when the prometheus exporter is selected, so a default deployment exposes no new surface and requires no collector configuration.
4. The exporter is command-metrics only: spans are not exported in this mode (a startup warning makes that explicit). The reader-fork lifecycle gap noted as point 5 in the issue is a separate bug and is intentionally left out of this PR.
5. A single-process deployment (plain uvicorn, no gunicorn) works without the state directory and serves its own in-process registry.

Configuration

[otel]
is_enabled = true
exporter_type = "prometheus"          # "console" | "otlp" | "prometheus" | "none"
prometheus_multiproc_dir = "/tmp/pr-agent-prometheus"  # shared, writable by every worker

The directory can be mounted as a volume for durability; when_ready creates it when missing. Example scrape config:

scrape_configs:
  - job_name: pr-agent
    static_configs:
      - targets: ["pr-agent:3000"]

How this was verified

1. Unit tests translate an OTel counter into the Prometheus text format through the real MeterProvider + PeriodicExportingMetricReader path, including name sanitization (pr_agent.commands → pr_agent_commands_total) and label-key sanitization (provider.name → provider_name).
2. A multiprocess end-to-end test runs the exporter in two fresh interpreter processes (as gunicorn workers would) and asserts /metrics merges both workers' state files.
3. The exporter-type validation, tracer/meter agreement, config provisioning of the state dir, and shipped defaults are covered in the telemetry tests.
4. A test verifies the module can be imported without importing prometheus_client (gunicorn master safety under preload_app).
5. Full unit suite: 4459 passed;ruff and pre-commit hooks clean.

closes The-PR-Agent#3191