Mettre en place du rate limiting

# Implémenter le Rate Limiting

## 📋 Contexte
L'application MCP grandit et nécessite une protection contre les abus, les erreurs de configuration ou les pics de charge involontaires. Nous allons implémenter un système de rate limiting en utilisant la librairie [`limits`](https://github.com/alisaifee/limits) pour contrôler le débit des requêtes entrantes.

## 🎯 Objectif
Mettre en place un rate limiting basée sur l'IP du client **progressif et évolutif** :

## 🔧 Détails techniques
- Librairie : `limits` (ex: `limits>=3.5.0`)
- Intégration : Middleware / Decorator adapté au framework MCP actuel (FastAPI/Starlette/Flask/etc.)
- Configuration : Externalisée via variables d'environnement ou fichier YAML/JSON

## ✅ Critères d'acceptation
- [ ] La librairie `limits` est installée et intégrée au pipeline de build
- [ ] Le rate limiting s'applique sur tous les tools MCP (via middleware ou décorateur)
- [ ] Retourne un `HTTP 429 Too Many Requests` avec les en-têtes standards :
`Retry-After`, `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`
- [ ] Les logs sont configurés pour tracer les déclenchements (`WARNING` ou `INFO`) sans saturer le système
- [ ] Documentation technique mise à jour (architecture, configuration, endpoints ciblés, stratégie d'évolutivité)

Start by identifying the current MCP request entry point and framework integration, then inspect the build configuration and existing logging setup. Integrate the limits library across all MCP tools, return HTTP 429 with the specified headers, record rate-limit events without log saturation, and update the architecture and configuration documentation.

Written by the indexing model from the issue text.