[FEATURE] add notification mail event

[acapai]

Système de notifications digest pour les nouvelles collectives

---

Ce que propose cette branche

Cette PR introduit un système de notifications email groupées (digest) pour alerter les membres de la création de nouvelles collectives. Les utilisateurs s'abonnent via leur profil, choisissent leur fréquence, et reçoivent un email synthétique (quotidien ou hebdomadaire) listant uniquement les collectives qui correspondent à leurs filtres.

Les notifications de supervision vers les boîtes activité (comportement existant) sont préservées et non modifiées.

---

Fonctionnalités livrées

Fonctionnalité	Détail
Abonnement opt-in	Case à cocher sur le profil, désactivée par défaut
Digest quotidien ou hebdomadaire	Configurable par l'utilisateur, envoi à 8h (lundi pour le weekly)
Filtrage fin	Par type d'activité, type d'événement, jours de semaine
Vérification de licence à l'envoi	Un abonné sans licence valide au moment du digest ne reçoit rien
Tracking des clics	Chaque lien est signé par token — un clic met à jour la date d'engagement
Désabonnement one-click	Lien en bas de chaque email, sans nécessiter d'être connecté
Gestion de l'inactivité	Après 365 jours sans clic : préavis par email. Après 14 jours sans réaction : désabonnement automatique
CLI de maintenance	flask send-new-event-digests et flask maintain-new-event-notifications
Migration Alembic	2f4d0f7a9c3b — 6 colonnes sur users, 2 tables de jonction, 1 table queue
Tests d'intégration	Digest, inactivité, clic, désabonnement, préférences profil

---

Architecture — schéma de flux

Création d'une collective
        ↓
email_templates.py → send_new_event_notification()
        ├── → Superviseurs activité (immédiat, inchangé)
        └── → queue_new_event_notification() → table new_event_notifications

[CRON 8h quotidien]
flask send-new-event-digests
        ↓
Pour chaque abonné dû :
  - Filtre par licence, type d'événement, activité, jours
  - Génère email avec liens signés
  - Mémorise last_sent_at

[CRON hebdo]
flask maintain-new-event-notifications
        ↓
  - 365j sans clic → préavis
  - 365j + 14j → désabonnement automatique

---

Travail de comparaison avec la PR #877

Les deux PR convergent vers le même objectif : permettre aux membres d'être informés des nouvelles collectives correspondant à leurs intérêts, avec abonnement via le profil, filtrage par activité, et lien de désabonnement dans les emails.

Cett PR répond à ces mêmes besoins et apporte en plus :

• Envoi asynchrone par digest — les emails ne sont pas envoyés dans la requête web mais mis en queue, puis expédiés en lot par un cron. Cela évite la contention SMTP et les timeouts lors de la création d'une collective.

• Désabonnement one-click sans login — les routes /click/ et /unsubscribe/ sont explicitement exemptées d'authentification. Le token signé suffit. Dans l'autre branche, la route reste derrière @valid_user(), ce qui impose en pratique d'être connecté pour se désabonner depuis un email.

• Pas de doublon d'envoi possible — un watermark last_sent_at par utilisateur et une purge de la queue garantissent qu'une même collective n'est jamais envoyée deux fois.

• Qualification des destinataires à l'envoi — licence valide, compte actif et filtres métier sont vérifiés au moment de l'envoi du digest, pas seulement à la souscription.

• Politique d'inactivité RGPD — après 365 jours sans clic sur un lien de notification, un préavis est envoyé. Sans réaction sous 14 jours, l'abonnement est automatiquement coupé.

• Filtrage fin par jour de semaine — en plus des types d'activités et d'événements, l'utilisateur peut restreindre ses notifications aux collectives débutant certains jours de la semaine.

• Outillage opérationnel complet — deux commandes CLI dédiées (flask send-new-event-digests, flask maintain-new-event-notifications), un exemple de fichier cron, et une documentation Sphinx.

• Couverture de tests d'intégration — queue, scheduling, tokens publics, rendering HTML, purge, inactivité, préférences profil. L'autre branche couvre uniquement les méthodes modèles en tests unitaires, sans couverture des routes de notification ni de l'envoi email.

---

Fichiers modifiés / créés

Fichier	Nature
collectives/new_event_notifications.py	Nouveau — queue, digests, inactivité, CLI
collectives/models/new_event_notification.py	Nouveau — modèle table queue
collectives/models/user/model.py	Modifié — 6 colonnes + 2 relations
collectives/models/user/misc.py	Modifié — méthodes inactivité, slot, filtrage
collectives/models/user/enum.py	Modifié — NotificationFrequency
collectives/routes/profile.py	Modifié — routes préférences, click, unsubscribe
collectives/forms/user.py	Modifié — NotificationPreferencesForm
collectives/templates/profile/notification_preferences.html	Nouveau — page préférences
collectives/email_templates.py	Modifié — hook vers queue
collectives/__init__.py	Modifié — enregistrement serializer + CLI
migrations/versions/2f4d0f7a9c3b_add_user_new_event_notifications.py	Nouveau — migration
tests/test_new_event_notifications.py	Nouveau — tests dédiés
doc/cron/collectives-notifications.cron	Nouveau — exemple planification
doc/source/notifications_digest.rst	Nouveau — documentation opérationnelle

---

Points d'attention pour la review

• Les routes /profile/user/notifications/click/<token> et /profile/user/notifications/unsubscribe/<token> sont volontairement exemptes d'authentification — elles sont accessibles depuis un email. La sécurité repose sur le token signé itsdangerous.URLSafeTimedSerializer.
• L'heure d'envoi (8h00) est hardcodée dans collectives/models/user/misc.py — non configurable via app.config ni Configuration.
• Le cron doit être configuré côté serveur — voir doc/cron/collectives-notifications.cron.

Refs #877
Closes #873