feat: Track upstream provider rate-limit headers

[tito]

What changed

• Providers accept a rate_limit_headers map from metric key to upstream header name. Six keys: limit_requests, remaining_requests, limit_tokens, remaining_tokens, reset_requests, reset_tokens. Empty means the provider is not tracked.
• One capture site in internal/server/openai.go, after the upstream response head and before the unary/stream branch. Regression tests cover both paths.
• The latest reading per provider is kept in memory. Finished minute buckets are written to a new provider_rate_limit_sample table, one row per provider per minute with the last and the lowest remaining value. The open bucket is flushed at shutdown.
• Proxied responses carry x-llmproxy-ratelimit-{requests,tokens}-{limit,remaining} headers.
• Prometheus gauges llmproxy_provider_rate_limit_remaining and llmproxy_provider_rate_limit_limit, labelled by provider and unit.
• GET /stats/rate-limits returns the snapshot per provider with a stale flag. GET /stats/rate-limits/series returns the minute buckets for one provider over a time range.
• Admin API accepts and validates rate_limit_headers on provider create and patch.
• UI: a rate-limit block on the provider form with a "Use standard headers" preset, and a Providers sub-tab under Usage with one card per tracked provider showing remaining over limit and the age of the reading. Existing dashboards are unchanged.
• Docs: providers guide, API reference, architecture rule.

Why

Some upstreams, tensorx today, report their quota on every response. The proxy read none of those headers and did not forward them, so neither callers nor operators could tell how close the provider was to refusing requests. This change observes and exposes the values. It does not throttle.

Testing

• go test -race -count=1 ./... passes.
• golangci-lint run reports no issues.
• UI rebuilt; the committed internal/server/uidist/ matches.
• mkdocs build --strict passes.

Notes

• Nothing on this path reads a request or response body. The new column names pass the persistence schema test.
• Two replicas that roll over the same minute hit the UNIQUE constraint. One row wins and the conflict is ignored.
• PruneRateLimitSamples exists in the store but nothing calls it yet. One active provider adds about 1440 rows a day. A retention job is a follow-up.
• Rate limits are tracked per provider, not per model. If tensorx scopes limits per model, the sample key needs an upstream_name column.