Replace Synchronous HTTP Clients with Async Alternatives in AI Endpoints

### **Problem Description**

The AI endpoints in ai.py currently use synchronous HTTP libraries (`requests`) within async FastAPI route handlers. This creates a performance bottleneck that significantly impacts the application's ability to handle concurrent requests efficiently.

**Current problematic patterns:**
```python
# Blocking synchronous calls in async context
@router.get("/api/trending-niches")
def trending_niches(): # Should be async
resp = requests.get(url, timeout=10) # Blocks event loop
supabase.table("trending_niches").select("*").execute() # Also synchronous
```

### **Performance Impact**

- **Event Loop Blocking:** Synchronous HTTP calls block the entire event loop, preventing other requests from being processed
- **Thread Pool Exhaustion:** FastAPI falls back to thread pool execution (limited to 40 threads by default)
- **Poor Scalability:** Application cannot efficiently handle concurrent AI requests
- **Increased Latency:** Context switching overhead between threads adds unnecessary delays
- **Resource Waste:** Thread pool threads remain blocked during network I/O operations

### **Expected Behavior**

AI endpoints should use non-blocking, async HTTP clients that allow the event loop to process other requests while waiting for external API responses (Gemini AI, YouTube API, Supabase).

### **Additional Context**

This enhancement aligns with FastAPI's async-first architecture and is crucial for production deployments. The change will unlock the application's true concurrent processing potential, especially important for AI endpoints that involve multiple external API calls.