Invitations: cohérence, notifications destinataire et prévention des doublons

Nobody has claimed this yet.

---
# Description

Aujourd’hui, lorsqu’une invitation est acceptée, cela peut créer des doublons d’événements ou de tâches pour un même utilisateur si l’action est rejouée (ré-acceptation, latence réseau, clic multiple).
De plus, la notification générée lors de l’envoi cible l’expéditeur plutôt que le destinataire, ce qui complique le suivi côté invité.

---

# Problèmes à résoudre

- **Cohérence de l’acceptation** : harmoniser la lecture de `event_id` / `task_id` pour éviter les erreurs 404 et rendre l’acceptation idempotente.
- **Déduplication** : empêcher la création d’une copie d’événement/tâche si l’utilisateur cible possède déjà une instance liée.
- **Notifications** : générer une notification claire pour le destinataire (et éventuellement pour l’expéditeur) avec un message contextualisé (titre, expéditeur, date).
- **Validation email** : valider côté serveur (400 si invalide) et refléter l’erreur côté client.

---

# Impacts

- ✅ Meilleure UX (pas de doublons)
- ✅ Observabilité (notifications pertinentes)
- ✅ Robustesse des workflows d’invitations

---

# Pistes de solution

- **Contrat repository** : requêtes `SELECT/INSERT` idempotentes avec contrainte unique logique (`user_id`, `source_id`, `type`).
- **Lecture unifiée d’acceptation** : lire d’abord `event_id`, puis `task_id` ; si déjà copié, retourner `200` avec message `“déjà accepté”`.
- **Notifications** : ajouter une colonne de cible (`user_id` destinataire) et uniformiser les messages.

---

# Critères d’acceptation

- Une ré-acceptation retourne `200` sans créer de nouvelle ressource.
- Le destinataire reçoit une notification exploitable (JSON), visible en UI.
- Les tests couvrent `event_id` et `task_id`, y compris ré-acceptation / idempotence et validation d’email.
---

Trace the invitation acceptance flow, repository operations, notification creation, and server/client email validation; no specific files or tests are named. Start by locating the event_id/task_id handling and the notification target, then use the acceptance criteria to verify idempotent re-acceptance, event and task coverage, email errors, and UI-visible recipient notifications.

Written by the indexing model from the issue text.