feat(mcp): W2.5 — per-tool rate limit via mcp-tool.rate-limit

[jrosskopf]

Summary

• Adds opt-in per-tool rate limit for MCP tool calls:

  mcp-tool:
    name: customer_lookup
    rate-limit:
      enabled: true
      max: 100
      interval: 60

• Each tool gets its own bucket keyed on (tool_name, principal). Two tools have independent quotas; two callers on the same tool have independent quotas. The check runs in MCPToolHandler::executeTool BEFORE argument validation and BEFORE the SQL template is loaded — a flooded caller never consumes template I/O or DB resources.
• On denial: error_message starts with "Rate limit exceeded"; metadata carries rate_limited: true and retry_after_seconds.
• Closes W2.5 of the security roadmap (Security Wave 2: MCP hardening (per-tool RBAC, dry-run, response shaping, description hygiene) #24). The entire MCP wave is now covered.

Why a new limiter (not just RateLimitMiddleware)

All MCP tool calls land on the same HTTP path (/mcp/jsonrpc). Crow's middleware sees the URL path, not the tool name in the JSON-RPC body, so keying on req.url cannot separate tools. MCPToolRateLimiter keys on tool_name directly and lives inside the handler, which already has the parsed tool name in hand.

Test plan

• 8 Catch2 unit cases in test/cpp/mcp_tool_rate_limiter_test.cpp covering every branch with an injectable clock — disabled config always allows, max=N allows exactly N then denies, bucket resets after the interval, two tools have independent buckets, two principals on the same tool have independent buckets, retry_after equals seconds-until-reset, remaining decrements correctly, concurrent acquires honour the cap exactly (16 threads × 25 attempts, max=50 → exactly 50 allowed).
• 1 new parser case plus the existing MCP-tool case extended to assert the default is enabled: false.
• ctest -R "MCPToolRateLimiter|Parse MCP Tool" — 10/10 pass.
• 2 end-to-end Python cases in test/integration/test_mcp_per_tool_rate_limit.py boot a real flapi server with two tools at different limits, hammer them, and assert each tool blocks at its own threshold while leaving the other tool's bucket untouched. 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

• MCPToolRateLimiter has a single responsibility: hold per-bucket counters, decide allow/deny, return retry_after_seconds on denial. Clock function is injectable for deterministic tests; default uses steady_clock::now(). Thread-safe via mutex around the buckets map.
• Reuses the existing RateLimitConfig struct — no new config type. MCPToolInfo.rate_limit defaults to enabled: false so existing tools behave exactly as before.
• The check runs in the handler before any of the existing W2.1 (RBAC) / W2.2 (dry-run) / W2.3/W2.4 logic so it short-circuits cleanly.

Closes part of #24
Refs #21