/metrics doesn't aggregate across workers

docker-compose.prod.yml runs this service under 4 separate gunicorn worker processes, each with its own independent Prometheus metric objects — nothing shares them across processes. A single scrape of GET /metrics currently only reflects whichever one worker process happened to answer that connection, not a true sum across all 4. This is called out explicitly in the project README's known limitations, and matters for the same reason GET /events/stats has the same per-process blind spot: a dashboard built on either number under-reports by roughly 4x, depending on which worker answers.

get_metrics_registry() is already the single place /metrics asks which registry to export, but its body always returns the plain global REGISTRY, ignoring the PROMETHEUS_MULTIPROC_DIR environment variable that prometheus_client's own multiprocess mode is built around.

1. pytest practice_tickets/tests/test_ticket_20_multiprocess_metrics.py -v — sets PROMETHEUS_MULTIPROC_DIR to a real directory and confirms get_metrics_registry() still returns the same global REGISTRY object.

prometheus_client ships first-class support for exactly this multi-process scenario (a well-known limitation of any pre-fork server model), but it requires each worker to write its metric state to files in a shared directory and the reading side to use MultiProcessCollector against a fresh CollectorRegistry instead of the default global one. This ticket is scoped to the reading side — making get_metrics_registry() actually branch on PROMETHEUS_MULTIPROC_DIR — which is the piece this codebase currently gets wrong even before the writing side is considered.

Look at get_metrics_registry() in app/metrics.py — note the already imported-but-unused os module at the top of the file (a hint, not an accident). You'll need prometheus_client.multiprocess.MultiProcessCollector and a fresh CollectorRegistry() to register it against, conditioned on whether os.environ.get("PROMETHEUS_MULTIPROC_DIR") is set.