Backend logs a DEBUG line per middleware per request, including health probes

Every request logs several DEBUG lines, including unauthenticated health probes. A single GET /health/ produces:

{"event": "Rate limit check - Method: GET, Path: /health/, IP: 127.0.0.1, Count: 11/5000, Reset in: 3299s"}
{"event": "Setting user from Keycloak token", "logger": "authorization.middleware.keycloak_auth", "level": "debug"}
{"event": "Validating token for request", "logger": "authorization.middleware_utils", "level": "debug"}
{"event": "No token found, returning anonymous user", "logger": "authorization.middleware_utils", "level": "debug"}
{"event": "User set: AnonymousUser, authenticated: False", "logger": "authorization.middleware.keycloak_auth", "level": "debug"}
{"event": "Starting new HTTP connection (1): elasticsearch:9200"}
{"event": "http://elasticsearch:9200 \"HEAD / HTTP/1.1\" 200 0"}
INFO:     127.0.0.1:51850 - "GET /health/ HTTP/1.1" 200 OK

Eight lines for one unauthenticated probe that does nothing interesting.

Why it is worth fixing

• /health/ is hit by the Docker healthcheck, the deploy gate and any monitoring, so this repeats continuously.
• The rate_limit middleware logs on every request regardless of level, including ones nowhere near the limit (11/5000).
• It makes real signals hard to find. During the 429 incident on 2026-09-03 the useful lines — the actual 429 and the OperationalError — were buried in this. Someone reading these logs reasonably assumed something was wrong when nothing was.

Suggested

• Set the log level to INFO for the dev deployment; the auth middleware lines are genuinely debug-only.
• Consider logging the rate-limit check only when the count crosses some fraction of the limit, or only on rejection. A line per request that says "well under the limit" is noise; a line that says "80% consumed" is a signal.

Low priority: noise and I/O, not a defect.