feat(security): W1.4 — per-user rate limiting via rate-limit.key

[jrosskopf]

Summary

• Adds a key knob to the rate-limit config that controls how requests are grouped into buckets:

  rate-limit:
    enabled: true
    max: 100
    interval: 60
    key: user-or-ip       # ip | user | user-or-ip

• ip keeps the historic per-client-IP behaviour. user keys on the (hashed) Authorization header — two bearer tokens from the same IP land in two buckets, one user roaming between IPs stays in one bucket, anonymous traffic shares an anonymous bucket. user-or-ip uses the user identifier when present and falls back to IP otherwise.
• Closes W1.4 of the security roadmap (Security Wave 1: Quick production wins (bcrypt, CORS allowlist, audit log, per-user rate limit) #23). Unlocks W2.5 (per-tool MCP rate limits) — the same RateLimitKeyBuilder will plug in once tool-specific limits land.

Test plan

• 11 Catch2 unit cases in test/cpp/rate_limit_key_builder_test.cpp: ip ignores Auth, user differentiates two tokens from the same IP, user ignores IP, anonymous maps to a stable shared bucket, user-or-ip falls back correctly, path is part of every key, hashing is deterministic, raw token never appears, enum parsing handles unknown values.
• ctest -R RateLimitKey — 11/11 pass.
• 2 end-to-end Python cases in test/integration/test_per_user_rate_limit.py boot real flapi servers with low quotas and verify user-or-ip isolates two bearer tokens at the same IP into separate quotas while ip pools them into one. They skip cleanly in environments with the existing DuckDB v1.5.1/v1.5.2 extension-cache mismatch; CI runs against fresh extensions.

Design notes

• RateLimitKeyBuilder is a pure single-responsibility helper: (strategy, ip, authorization_header, path) → bucket_key. No Crow, no ConfigManager — testable in isolation.
• The Authorization value is hashed via std::hash before it lands in the bucket key. This is deliberately non-cryptographic — we only need determinism and to keep the raw token out of debug logs. Operators who want stronger guarantees can put a reverse proxy in front and key on a header it injects.
• RateLimitKeyStrategyUtils::parse falls back to ip for unknown/empty values, so fat-fingered configs do not silently flip to a different scheme.
• No middleware-ordering changes: the Authorization header is read directly from the request, so we do not depend on AuthMiddleware running first.

Closes #23 (rate-limit portion)
Refs #21