fix: fail closed on an unwritable audit log, bound the rate limiter and harden startup

The audit logger is opened at startup (exit 2 on failure) and obtained before
every call, which is refused with audit_unavailable otherwise. Audit records only
take validated path and sudo values and use the request id as correlation id. The
rate limiter evicts idle keys, caps tracked keys, audits the first excess per key
and window and uses the settings passed to the app. FORWARDED_ALLOW_IPS is now a
setting, and startup warns about a missing host allow-list and unavailable OAuth.

docs/deployment.md

@@ -81,7 +81,15 @@ in mind for long tool calls.
 
 The server rejects requests whose `Host` is not allowed (DNS-rebinding protection). Allowed hosts
 are the loopback names with the port, the host of `PUBLIC_BASE_URL`, and `ALLOWED_HOSTS`. If
-you reach it under another name, add that name to `ALLOWED_HOSTS`.
+you reach it under another name, add that name to `ALLOWED_HOSTS`. With a non-loopback
+`MCP_HOST` (the container) and neither `PUBLIC_BASE_URL` nor `ALLOWED_HOSTS`, every remote `Host`
+is rejected with 421, and the server logs a warning at startup naming the two variables.
+
+The server trusts `X-Forwarded-For` only from `FORWARDED_ALLOW_IPS` (default `127.0.0.1`). When
+the proxy reaches the container from another address, for example a Docker network, add that
+address or network (`FORWARDED_ALLOW_IPS=172.18.0.0/16`). Without it every request looks like it
+comes from the proxy and shares one per-IP rate limit bucket. `*` trusts any peer, so use it only
+when the port is reachable solely from the proxy.
 
 ## OAuth application in Gitea