Ajouter une vue des tâches et jalons groupés par mois

La frise répond mal à « qu'est-ce qui arrive le mois prochain » : la question
traverse les projets, alors que la frise les range précisément en couloirs
séparés. Il fallait balayer une colonne de dates à travers tous les couloirs
en gardant en tête ce qu'on avait vu plus haut — d'où le tableur ressorti à
côté.

Deux boutons dans la barre d'outils basculent vers une liste qui déroule
toutes les phases, projets mêlés, dans l'ordre du calendrier. Chaque ligne se
lit quand, chez qui, puis quoi : période, projet et ses tags, intitulé,
statut.

Une phase est rattachée au seul mois de son début. La répéter dans chaque mois
traversé aurait donné un tableau de charge — utile, mais c'est une autre vue,
et le doublon coûte la lecture en diagonale qui fait tout l'intérêt de
celle-ci. Sa fin est écrite sur la ligne, ce qui suffit à voir qu'elle
déborde. Les mois sans rien ne sont pas représentés : l'absence se lit déjà
dans le saut d'un titre au suivant.

La liste ne s'édite pas, et ce n'est pas une lacune à combler : déplacer une
phase demande de voir ce qu'elle chevauche et ce qu'elle repousse, or c'est
justement ce voisinage que l'ordre chronologique dissout. Seules les pastilles
de tags restent cliquables — filtrer ne change pas les données.

Le filtre par tags vaut pour les deux vues, sans rien changer à sa mécanique,
si bien qu'on ne se demande jamais si l'une montre plus que l'autre. L'œil
(hidden) écarte un projet de la liste comme il écarte ses barres.

La vue choisie n'est pas enregistrée, contrairement à la largeur de la colonne
des libellés : cette largeur est un réglage d'écran, la vue est un geste de
consultation. L'outil s'ouvre donc sur la frise, celle où l'on modifie. Le
défilement horizontal de la frise, lui, est mémorisé le temps de
l'aller-retour, puisque masquer un élément lui fait perdre son scrollLeft.

Deux extractions au passage, chacune parce que deux vues sœurs en ont besoin
et qu'aucune n'a à importer l'autre : les noms de mois et le formatage des
dates rejoignent model.js, les pastilles de tags un module tags.js.

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

docs/decisions.md

@@ -531,3 +531,50 @@ planning dans git, ce que son format texte indenté rend parfaitement lisible (v
 Ce changement a rendu concurrentes deux étapes qui ne l'étaient pas — la copie et le remplacement
 dépendent maintenant d'un état partagé, la date de la dernière sauvegarde. Un verrou les sérialise,
 ce qui protège au passage du cas où deux onglets enregistrent en même temps.
+
+## 24. Une vue par mois, en lecture seule, à côté de la frise
+
+La frise répond très bien à « comment ce projet-là s'étale-t-il », et très mal à « qu'est-ce qui
+arrive le mois prochain ». La seconde question traverse les projets, alors que la frise les range
+précisément en couloirs séparés : il faut balayer une colonne de dates à travers tous les couloirs,
+en gardant en tête ce qu'on a vu plus haut. Avec cinq projets et une échelle de six pixels par
+jour, c'est déjà pénible ; c'est la raison pour laquelle on ressortait un tableur à côté.
+
+D'où une seconde vue, atteinte par deux boutons dans la barre d'outils. Trois arbitrages la
+définissent.
+
+**Une phase est rattachée au mois de son début, et à lui seul.** Une phase de trois mois n'apparaît
+donc qu'une fois. La répéter dans chaque mois traversé aurait donné un tableau de charge —
+« qu'est-ce qui tourne en octobre » —, qui est une question légitime mais une autre vue : le
+doublon coûte la lecture en diagonale qui fait tout l'intérêt de celle-ci, et brouille le compte
+affiché en tête de mois. La fin est écrite sur la ligne (« 31 → 13 nov. »), ce qui suffit à voir
+qu'une phase déborde et jusqu'où.
+
+**Les mois sans rien ne sont pas représentés.** Un planning à horizon de deux ans a des trous ;
+intercaler « novembre 2026 — rien » ferait défiler du vide, alors que l'absence se lit déjà dans le
+saut d'un titre au suivant.
+
+**La liste ne s'édite pas.** Aucune poignée, aucun glisser, et un clic sur une ligne n'ouvre pas le
+panneau de détail. Ce n'est pas une lacune à combler plus tard : déplacer une phase demande de voir
+ce qu'elle chevauche et ce qu'elle repousse, c'est-à-dire le voisinage que la frise montre et que
+la liste, ordonnée par date et non par projet, a justement dissous. Une date qu'on modifie sans
+voir son contexte est une date qu'on modifie à l'aveugle. La vue sert donc à faire le point, la
+frise à arbitrer. Seules les pastilles de tags restent cliquables — filtrer ne change pas les
+données, c'est une façon de regarder.
+
+Le filtre par tags, lui, vaut pour les deux vues sans rien changer à sa mécanique : c'est le même
+état, la même barre, au même endroit. Un filtre posé sur la frise se retrouve en passant à la
+liste, ce qui rend la bascule sûre — on ne se demande jamais si l'une montre plus que l'autre. Les
+deux tamis de la frise s'appliquent d'ailleurs à l'identique : l'œil (`hidden`) écarte un projet de
+la liste comme il écarte ses barres.
+
+La vue choisie n'est pas enregistrée, contrairement à la largeur de la colonne des libellés
+(décision 18). Cette largeur est un réglage d'écran, la vue est un geste de consultation : on passe
+par la liste pour faire le point, on revient à la frise pour travailler. L'outil s'ouvre donc
+toujours sur la frise, celle où l'on modifie. Le défilement horizontal de la frise, lui, est
+mémorisé le temps de l'aller-retour : masquer un élément lui fait perdre son `scrollLeft`, et
+revenir des années avant ce qu'on regardait serait une punition pour avoir consulté la liste.
+
+Deux conséquences dans le code, toutes deux de bon aloi : les noms de mois et `formaterDateLongue`
+sont remontés de `timeline.js` vers `model.js`, et les pastilles de tags dans `tags.js`. Deux vues
+sœurs les emploient, aucune n'a à importer l'autre pour écrire « septembre ».