fix(recommendations): invalidate all cache variants via pattern matching

[Peaostrel]

Fixes #816

Overview

Previously, invalidate() in RecommendationEngineService only cleared recommendation cache variants for specific hardcoded limits (5, 10, 20, 50). If a client requested recommendations with custom limits (e.g., 15 or 100), those cache keys were never invalidated after a new enrollment, serving permanently stale recommendations.

This PR resolves the issue by implementing a wildcard pattern deletion mechanism, ensuring all limit variants for a specific user are properly cleared.

Changes

• Added deleteByPattern to CachingService: Natively uses Redis SCAN + DEL for safe, non-blocking cache invalidation of pattern-matched keys. It gracefully falls back to .keys() for non-Redis cache stores.
• Updated invalidate(): Modified RecommendationEngineService to delete all keys matching the recommendations:{userId}:* namespace prefix instead of an array of hardcoded limits.
• Updated Tests: Added tests for deleteByPattern and updated recommendation engine specs to mock and verify the new pattern deletion logic.

Acceptance Criteria Met

• All recommendation cache variants are invalidated when a new enrollment occurs.
• invalidate() is idempotent and safe to call when no cached key exists (Redis SCAN handles empty matches safely and efficiently without throwing errors).

[drips-wave]

@Peaostrel Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project.