Add per-customer rate limiting to analytics ingestion endpoint using Bucket4j

Description

Add per-customer rate limiting to the ingestion endpoint using Bucket4j (in-process, token bucket algorithm). Each customerId gets its own bucket. When the bucket is exhausted, return 429 Too Many Requests. Rate limit parameters (capacity, refill rate) must be configurable — not hardcoded.

Improvement plan: https://docs.google.com/document/d/1hVfIurPqAJJ1PN1EalmvrWXnGNt5sY21MI-409lrXpU/edit?tab=t.klqavlz4cis7#heading=h.8vek9yxwq8yt

Parent epic: #35048

Acceptance Criteria

• Bucket4j added as a dependency
• Each customerId gets its own in-process token bucket
• Rate limiting enforced on the ingestion endpoint only
• Exhausted bucket returns 429 Too Many Requests
• Rate limit capacity and refill rate configurable via application.yml (not hardcoded)
• Web layer test added: rate-limited request returns 429
• Rejection logged with structured JSON

Additional Context

• Source task: Task 19 (Per-customer rate limiting) from the improvement plan
• Parallelizable after Phase 1 — blocked by: #35050
• Implementation: in-process only (no Redis); swappable to distributed later if needed
• Related branch: issue-34849-Add-dotCMS-Analytics-Proxy-Endpoint-for-/v1/analytics/-to-dot-ca-event-manager

Start at the analytics ingestion endpoint and inspect the related branch and blocking issue #35050 before changing behavior. Review application.yml for configurable capacity and refill settings, then add the requested web-layer test for a 429 response and verify structured rejection logging.