feat(server): cap the request rate per caller

[ekalinin]

Stacked on #18.

Problem

The defaults.max_concurrent_queries semaphore bounds how many queries run at once, but nothing bounded how fast they could be submitted. One client could still churn through pool connections, storage writes and idempotency keys as fast as the process could accept or reject them.

Change

server.rate_limit.{requests_per_second,burst} gives each caller a token bucket. The key is the authenticated subject where there is one, and the resolved client address otherwise - the address that the ClientIPFrom* middleware produced, so it already accounts for the configured number of trusted proxy hops.

It runs on both transports: a chi middleware in REST and an interceptor in Connect that covers unary and streaming calls.

Idle buckets are evicted, so the map cannot grow without bound on a busy or hostile deployment; the sweep is amortized to at most once per eviction window.

The /healthz and /readyz probes are exempt: the kubelet calls them on a schedule and must neither be starved by a noisy caller nor consume that caller's budget.

requests_per_second: 0 disables the limit, and startup logs a warning in that case so an absent limit is a visible decision rather than an oversight.

Tests

The bucket admits the burst and refuses the next request; budgets do not bleed between keys; a disabled limiter admits everything; the key prefers the subject over the address; in REST four requests give 200, 200, 429, 429 while the probes keep answering 200.

Verification

go test -race ./..., golangci-lint run ./... - clean.