Configuration: API/CORS — éviter “/api/api”, ORIGIN fiable et logs propres

Nobody has claimed this yet.

# Description

Des erreurs `404` apparaissent lors de la connexion à cause d’un doublon de chemin (`/api/api`).
Les logs indiquent également `CORS ORIGIN autorisé: undefined`, ce qui génère de la confusion et complique le débogage.

---

# Problèmes à résoudre

- **Client** : rendre `API_BASE_URL` idempotent → ajouter `/api` uniquement si absent, gérer les trailing slashes.
- **Serveur** : définir une valeur par défaut claire pour `ORIGIN` en développement et exiger une valeur explicite en production. Réduire les logs verbeux ou mal renseignés.
- **Documentation** : préciser le format attendu de `REACT_APP_API_URL` (avec / sans `/api`) et fournir des exemples valides pour dev/prod.

---

# Impacts

- ✅ Suppression des erreurs `404 / 401` inutiles
- ✅ Configuration reproductible entre les environnements
- ✅ Logs plus clairs, débogage plus rapide

---

# Pistes de solution

- **Client-side guard** :
- Normaliser `RAW_BASE` dans `config.ts`
- Empêcher l’ajout double de `/api`
- Ajouter des tests unitaires sur la normalisation
- **CORS** :
- Liste blanche simple (`localhost`, URLs dev connues)
- `ORIGIN` obligatoire en production
- Logs affichés uniquement selon `NODE_ENV`

---

# Critères d’acceptation

- Aucun appel réseau ne doit partir en `"/api/api"`.
- En développement :
- CORS ne logge plus `undefined`.
- En production :
- Le serveur refuse proprement si `ORIGIN` est absent ou invalide.
---

Start with the client config.ts and trace how RAW_BASE and REACT_APP_API_URL are normalized, then inspect the server CORS setup and its ORIGIN handling. Add unit tests for URL normalization and verify development and production behavior against the acceptance criteria, including clean logs and rejection of missing or invalid production configuration.

Written by the indexing model from the issue text.