ci: pipeline Gitea Actions build & push Docker sur push main

- Dockerfile multi-stage (build eclipse-temurin:25-jdk → runtime)
- CI : tests via actions/setup-java puis build & push vers registry Gitea
- Trigger Watchtower après push sur main
- CLAUDE.md + rules projet (.claude/rules/)
- Version build.gradle : 0.0.1-SNAPSHOT → 0.0.1

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/rules/webapp-integration.md

@@ -0,0 +1,33 @@
+# Intégration avec Olhar-webapp (frontend)
+
+## Principe
+
+Olhar-API est le backend consommé par **Olhar-webapp** (Angular). Tout changement d'API susceptible d'impacter le frontend doit être signalé.
+
+## Quand créer une issue sur Olhar-webapp
+
+Créer une issue sur **https://git.goutailler-olivier.com/Gato/Olhar** lorsque :
+- Un endpoint change de signature (URL, méthode, corps, réponse)
+- Un nouveau champ est ajouté à une réponse existante (à exploiter côté frontend)
+- Un endpoint est supprimé ou déprécié
+- Un comportement d'erreur change (code HTTP, format du message)
+
+## Contenu de l'issue
+
+L'issue doit décrire :
+- L'endpoint concerné (méthode + URL)
+- Ce qui a changé dans l'API
+- L'action attendue côté frontend (adapter l'appel, afficher un nouveau champ, etc.)
+- Si un feature flag côté frontend couvrait l'absence de cet endpoint, préciser qu'il peut être **retiré** maintenant que l'API est disponible (nettoyage du code mock et du flag correspondant)
+
+## CORS et sécurité
+
+- Les origines autorisées sont configurées dans `SecurityConfig`.
+- En développement : `http://localhost:4200` (Angular dev server).
+- Ne pas ouvrir `*` en production.
+
+## Contrat d'API
+
+- Les DTOs de réponse (`interfaces/rest/dto/response/`) constituent le contrat public.
+- Ne jamais modifier un champ existant d'un DTO sans créer une issue sur Olhar-webapp.
+- Ajouter des champs est non-cassant ; en supprimer ou en renommer est cassant.