docs: define strict dry-run contract

# Conflicts:
#	.secrets.baseline

TODO.md

@@ -147,7 +147,8 @@ Synchroniser différentiellement les événements Pronote vers le calendrier Cal
 
 - Le plan de sync est correctement calculé (données Pronote vs événements distants gérés).
 - Un changement de source iCal ↔ `pronotepy` ne crée ni doublon ni suppression/ajout artificiel pour un cours équivalent.
-- Un run dry-run n'écrit rien ; deux runs identiques donnent un résultat identique.
+- Un run dry-run autorise les lectures, mais ne produit aucune sortie distante ni écriture locale
+  persistante ; `qr_token` est refusé avant connexion. Deux runs identiques donnent le même résultat.
 - Les événements annulés restent (`STATUS:CANCELLED`) et sont marqués `MANAGED`.
 - Les événements non marqués ne sont jamais modifiés ni supprimés.
 
@@ -223,7 +224,9 @@ Composer et orchestrer toutes les étapes avec gestion d'erreurs dégradée et m
 - [x] Créer les étapes `pipeline/steps/` : `fetch.py`, `normalize.py`, `compare.py`, `caldav_sync.py`, `synthesis.py`, `send.py`, `fetch_blog.py`.
 - [x] Créer `pipeline/run.py` : `PipelineRunner` (composition root) orchestrant fetch → normalize → fetch_blog → compare → caldav_sync → synthesis → send.
 - [x] Gérer les erreurs dégradées (continuer sauf critique) et renvoyer `(PronoteData, erreurs + warns)`.
-- [x] Implémenter le mode `dry_run` (aucune écriture CalDAV/XMPP).
+- [x] Implémenter le mode `dry_run` : lectures autorisées, aucune écriture CalDAV/XMPP ni écriture
+  persistante locale ; l'état RSS reste en mémoire pendant l'exécution, et
+  `PRONOTE_AUTH_MODE=qr_token` est refusé avant toute connexion.
 - [x] Câbler l'injection des dépendances (Protocol + composition root), sans singleton global.
 - [x] Réutiliser, dans une même exécution, un unique téléchargement/parsing iCal pour l'agenda et les devoirs lorsque les sources sélectionnées le permettent ; rester sur un cache local au run, sans cache global ni persistant.
 
@@ -231,7 +234,9 @@ Composer et orchestrer toutes les étapes avec gestion d'erreurs dégradée et m
 - [x] Le pipeline complet s'exécute de bout en bout (mocks) dans le bon ordre.
 - [x] Une sélection iCal commune à l'agenda et aux devoirs ne déclenche qu'un téléchargement/parsing du flux par run.
 - [x] Une erreur non critique (ex : synthèse IA) n'empêche pas l'envoi XMPP.
-- [x] `dry_run=True` n'effectue aucune écriture ; aucune source disponible → erreur critique explicite.
+- [x] `dry_run=True` autorise les lectures mais n'effectue aucune écriture persistante locale ni
+  sortie distante ; aucune source disponible → erreur critique explicite. L'état RSS n'est pas
+  enregistré et `qr_token` est refusé avant toute connexion.
 - [x] Si `THEORETICAL_AGENDA_PATH` est absent, le pipeline produit un diff vide sans erreur et n'instancie pas `AgendaComparator` ; si présent, il instancie le comparateur et effectue la comparaison.
 - [x] Les erreurs critiques (`PipelineCriticalError`) propagées depuis une étape non-bloquante arrêtent le pipeline.
 
@@ -247,7 +252,8 @@ Exposer le lancement du pipeline via une interface en ligne de commande.
 - [x] Gérer le code de retour et l'affichage des erreurs (redactées).
 
 ### Critères d'acceptation
-- `pronote-sync --dry-run --log-level DEBUG` s'exécute sans effet de bord.
+- `pronote-sync --dry-run --log-level DEBUG` s'exécute sans sortie distante ni état local persistant ;
+  le mode `qr_token`, qui implique une rotation distante, est refusé avant connexion.
 - Le script console est installable (`[project.scripts]` dans `pyproject.toml`).
 - Les erreurs affichées ne contiennent aucun secret, y compris avec l'affichage d'un traceback complet en mode debug.