Refactor `api/admin.py` to Use Service/Repository Pattern

[gzark1]

Description

The api/admin.py file contains extensive direct database queries, violating the layered architecture. Almost every endpoint executes raw SQL via db.execute() instead of delegating to services/repositories.

Steps to Reproduce

1. Open backend/api/admin.py
2. Search for db.execute or await db.execute
3. Count occurrences: 30+ direct DB calls

Expected Behavior

API layer should only:

• Parse HTTP requests
• Call services for business logic
• Return HTTP responses

All database queries should go through Service → Repository layers.

Actual Behavior

API endpoints directly execute database queries:

• Lines 89-111: Query profiles, count interests
• Lines 268-273, 345-350: Count recommendations
• Lines 335-336: Add activity logs
• Lines 434-520: Analytics queries
• Lines 536-808: Distribution/growth queries
• Lines 829-943: Dashboard insights

Root Cause

The admin feature was built quickly without following the established layered architecture pattern used elsewhere (e.g., api/profiles.py → ProfileService → UserProfileRepository).

Possible Solutions

1. Option A: Create AdminService + AnalyticsRepository

   • Create services/admin_service.py for user management logic
   • Create repositories/analytics_repository.py for analytics queries
   • Refactor all endpoints to use these layers

2. Option B: Extend Existing Repositories

   • Add analytics methods to UserRepository
   • Add methods to RecommendationRepository
   • Create minimal AdminService for orchestration

3. Option C: Create AnalyticsService Only

   • Create services/analytics_service.py that encapsulates queries
   • Accept that some admin endpoints are thin wrappers
   • Focus on DRY principle rather than strict layering