Fix race condition in quota tracking using thread lock

[lakshayg2005]

Summary

This PR fixes a race condition in the user_quotas in-memory tracking system used for API rate limiting.

Previously, the quota dictionary was updated without any synchronization mechanism, which could lead to inconsistent behavior under concurrent requests.

---

Problem

The original implementation used a shared global dictionary:

user_quotas: Dict[str, Dict] = {}

This structure was modified directly in multiple requests:

• Initialization of new users was not thread-safe
• Increment operations were not atomic
• Concurrent requests could lead to incorrect quota counts or bypassing limits

---

Solution

Introduced thread-safety using threading.Lock to ensure atomic access to the quota dictionary.

Key changes:

• Added a lock to synchronize quota updates
• Wrapped quota check + increment inside a critical section
• Ensured consistent daily reset logic under concurrency

---

Impact

• Prevents race conditions in quota tracking
• Ensures accurate request counting under concurrent load
• Improves reliability of rate-limiting logic

---

Testing

• Verified /ask-llm endpoint with multiple sequential requests
• Simulated rapid requests using looped curl commands
• Confirmed quota decreases correctly per request
• Server runs without errors after changes

---

Notes

This is an in-memory solution suitable for single-instance deployments. For distributed systems, a centralized store like Redis would be more appropriate.

[chimosky]

Not reviewed, could you improve on your commit message?

[lakshayg2005]

@chimosky I’ve updated the commit message. Please review when convenient.