Two related issues showed up in the admin Security Logs / MCP Auth
Events widgets:

1. `security_events.ip_address` rows containing `register:9.9.9.9`,
   `oauth_login:9.9.9.9`, `ip1` — the rate-limit *bucket identifier*
   (composed by callers as `f"<endpoint>:{ip}"`) was logged verbatim
   instead of the real IP.

2. `data/logs/auth.log` and `auth_audit_log` rows referencing test
   fixtures (alice / dave / x users, `client.example.com` redirect URI,
   `chatgpt.com/callback` test redirect). Tests running on the host had
   been writing into the same `data/auth.db` and `data/logs/auth.log`
   that the live container reads — `get_config()` is a cached singleton
   that lazy-loads `.env` from cwd, and pytest from the project root
   resolved that to the prod paths.

Fix:

- `RateLimiter.check_limit()` accepts an `ip_address` keyword argument
  and uses it as the security_events.ip_address. Falls back to the
  identifier when not provided (backward compat). All seven call sites
  updated to pass the clean IP.
- `tests/conftest.py` autouse fixture wipes `_config_instance` and sets
  `AUTH_SQLITE_PATH` to a per-test tmp file, so any code that reaches
  the AppConfig via `get_config()` writes to a throwaway DB.
- Existing pollution scrubbed from `data/logs/auth.log` (283 rows),
  `auth.log.2026-05-09` (283 rows), `security_events` (99 rows),
  `auth_audit_log` (1 row). Backups under `/tmp/authmcp-cleanup-backup/`.

Two new regression tests cover both the clean-IP path and the
identifier-fallback path.