Sauvegarder une fois par séance plutôt qu'à chaque modification

L'interface enregistre après une seconde d'inactivité, et le serveur copiait
le planning avant chaque écriture : une après-midi d'édition produisait des
dizaines de fichiers quasi identiques.

Le problème n'est pas la place occupée mais ce que la rotation en faisait —
les cinquante emplacements se remplissaient en quelques heures et chassaient
les états anciens, les seuls qu'on cherche à retrouver. Un filet qui ne
remonte pas au-delà de la dernière demi-heure ne protège pas de la bêtise
qu'on découvre le lendemain.

La copie est désormais prise à l'ouverture, quand le planning est encore dans
l'état d'avant la séance. Deux garde-fous : au plus une par jour si le serveur
reste allumé longtemps, et rien du tout si le contenu n'a pas bougé depuis la
dernière copie. Les cinquante conservées couvrent maintenant des mois.

La copie et le remplacement partagent un état — la date de la dernière
sauvegarde — donc un verrou les sérialise, ce qui protège au passage du cas
où deux onglets enregistrent simultanément.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -168,8 +168,22 @@ Tout tient dans un fichier JSON, `data/projets.json`, décrit dans
 parlants (`site-web`, `cadrage`) plutôt que des UUID : il reste éditable à la main et lisible dans un
 diff git.
 
-À chaque sauvegarde, le serveur copie la version précédente dans un dossier `backups/` voisin du
-planning, horodatée.
+**À l'ouverture**, le serveur copie le planning dans un dossier `backups/` voisin, horodaté : c'est
+l'état d'avant la séance, celui qu'on veut retrouver si elle tourne mal. Si le serveur reste allumé
+plusieurs jours, une copie est reprise au plus une fois par jour. Rouvrir l'outil sans avoir rien
+modifié ne laisse pas de trace.
+
+Cinquante sauvegardes sont conservées, les plus anciennes étant supprimées au fil de l'eau. Comme
+elles valent une par séance et non une par modification, cela représente des mois d'historique
+plutôt que la dernière demi-heure.
+
+Pour restaurer, **arrêter `frise` et fermer l'onglet d'abord** : l'application garde son planning
+en mémoire et sa prochaine sauvegarde écraserait ce qu'on vient de remettre en place.
+
+```sh
+ls -lt backups/                          # repérer la version voulue
+cp backups/projets-20260801-170352.json projets.json
+```
 
 Le planning n'est **pas versionné** : `.gitignore` exclut `projets.json`, ce dépôt ne contenant
 que le code. Seul `data/exemple.json` y figure, comme jeu de démonstration.