Add query result caching with Spring Cache + Caffeine for analytics endpoints

Description

Add Spring Cache with Caffeine as the backing store. Apply @Cacheable to analytics query methods (total-events, unique-visitors, top-content). Use the Spring Cache abstraction to keep the implementation swappable to Redis later without changing application code.

TTL configuration:

• Per-endpoint TTL in application.yml (e.g. analytics.cache.total-events.ttl)
• Global fallback default TTL if no per-endpoint value is set

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

Parent epic: #35048

Acceptance Criteria

• Caffeine added as Spring Cache backing store
• @Cacheable applied to total-events, unique-visitors, and top-content query methods
• Per-endpoint TTL configurable via application.yml (e.g. analytics.cache.total-events.ttl)
• Global fallback default TTL used when no per-endpoint value is configured
• Cache uses Spring Cache abstraction (no direct Caffeine API calls in business logic)
• Unit test verifies cached method is not called twice for the same params within TTL window

Additional Context

• Source task: Task 22 (Query result caching) from the improvement plan
• Parallelizable after Phase 1 — blocked by: #35050
• Caffeine chosen for in-process simplicity; Spring Cache abstraction keeps Redis upgrade path open
• Related branch: issue-34849-Add-dotCMS-Analytics-Proxy-Endpoint-for-/v1/analytics/-to-dot-ca-event-manager

Start by locating the analytics query methods for total-events, unique-visitors, and top-content, then review application.yml for the existing configuration structure. Verify how Spring Cache can be configured with Caffeine and per-endpoint TTLs while keeping business logic independent of Caffeine. Done means all acceptance criteria pass, including a test that confirms repeated calls with the same parameters are cached within the TTL.