[FEATURE]: Add Rate Limiting and Abuse Protection for API Endpoints

### Feature and its Use Cases

### Feature Description

EduAid exposes multiple backend API endpoints that trigger expensive NLP model inference operations such as MCQ generation, short question generation, boolean question generation, and answer prediction.

Currently, these endpoints do not have any request rate limiting or abuse protection mechanism. Because the backend relies on large transformer models (e.g., T5, DistilBERT), repeated or automated requests could lead to excessive CPU/GPU usage and degrade overall system performance.

### Potential Use Case

If EduAid is deployed publicly, a user or automated script could send a large number of requests to model inference endpoints within a short time period. This could:

* Overload the backend server
* Increase response latency for other users
* Exhaust available compute resources
* Increase infrastructure cost

By introducing request rate limiting, the backend can restrict how many requests a single client can make within a given time window.

### Example Scenario

For example, a rate limit could be applied such as:

* **20 requests per minute per IP address**

If the limit is exceeded, the API would return a structured response such as:

```json
{
"error": "Rate limit exceeded",
"code": "rate_limit_exceeded"
}
```

This ensures that the system remains stable and fair for all users while preventing abuse.

### Benefits

* Protects the backend from request spam and automated abuse
* Improves reliability and stability under high traffic
* Reduces unnecessary compute usage from large models
* Makes the system safer for public deployment

### Additional Context

### Additional Context

This feature focuses on improving the stability and production-readiness of the EduAid backend. Since several endpoints trigger computationally expensive NLP pipelines and large transformer models, implementing rate limiting would help protect the system from excessive or automated requests.

Many production APIs use rate limiting to prevent abuse and ensure fair usage among users. Introducing this mechanism in EduAid would make the backend more reliable, especially if the service is deployed publicly or used by multiple users simultaneously.

Possible libraries that could be used include:

* **slowapi**
* **fastapi-limiter**
* **custom middleware implementation**

This change would not affect existing functionality but would add an important layer of protection and resource management for the backend.

### Code of Conduct

- [x] I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and will post updates there
- [x] I have searched existing issues to avoid duplicates