Prévient l'écran quand la saisie d'un numéro change sous ses pieds

« Ajouter ce numéro » restait grisé quel que soit le numéro tapé, et ne se
dégrisait qu'après un détour par « Modifier la revue » puis « Enregistrer ».
Ce n'était pas une validation fautive : Blazor ne redessine que le composant
qui a traité l'événement, et le bouton vit dans l'écran quand le champ vit
dans le composant. Le détour redessinait le parent, rien de plus.

Les champs du numéro passent donc tous par une propriété qui invoque
OnChangement — y compris ceux dont aucun bouton ne dépend aujourd'hui, pour
que la correction ne s'oublie pas au premier champ ajouté.

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

CLAUDE.md

@@ -3205,11 +3205,35 @@ titres **intacts**, un article ajouté à un numéro existant par l'écran d'éd
 qui se recharge bien d'un numéro à l'autre. Aucun débordement horizontal à 320 px
 (`scrollWidth` = 320).
 
-⚠️ **Défaut voisin constaté au passage, NON corrigé** : le bouton « Ajouter ce numéro » vit dans
-`Revue.razor` alors que le champ « Numéro » vit dans `ChampsNumeroRevue`. Une frappe ne
-re-rendant que le composant qui l'a traitée, le bouton **reste désactivé** tant que le parent ne
-se redessine pas — seul `Entrée` (qui appelle `OnEntree`, donc le parent) enregistre le numéro.
-À traiter.
+### ⚠️ Un champ dans l'enfant, le bouton dans le parent : le bouton reste figé
+
+Constaté au passage, puis remonté en usage : « Ajouter ce numéro » restait **grisé** quel que
+soit le numéro tapé, et ne se dégrisait qu'après un détour par « Modifier la revue » puis
+« Enregistrer ».
+
+**Blazor ne redessine que le composant qui a traité l'événement.** Le champ « Numéro » vit dans
+`ChampsNumeroRevue`, le bouton dans `Revue.razor` : une frappe re-rendait l'enfant, jamais le
+parent, dont l'attribut `disabled` restait celui du dernier rendu — c'est-à-dire celui d'un
+champ vide. Le détour « débloquait » parce qu'il redessinait le parent, pas parce qu'il validait
+quoi que ce soit. `Entrée` marchait déjà, lui, puisqu'il passe par `OnEntree`, donc par le
+parent.
+
+⚠️ **Le remède est une notification, pas un contrôle de saisie** : `OnChangement`, un
+`EventCallback` que l'enfant invoque — invoquer un callback du parent le redessine, c'est
+exactement ce qui manquait.
+
+⚠️ **Aucun champ ne se lie plus directement à `Saisie`** : tous passent par une propriété du
+composant qui prévient. Y compris ceux dont aucun bouton ne dépend aujourd'hui — faire dépendre
+la correction de « lequel commande quoi » la ferait oublier au premier champ ajouté.
+
+**Règle à retenir au-delà de ce cas** : un composant de saisie qui écrit dans un objet **prêté
+par son parent** doit prévenir ce parent, sinon tout ce que le parent calcule à partir de cet
+objet (bouton désactivé, compteur, message) reste figé sur l'état d'avant. Le symptôme est
+trompeur — on cherche une validation fautive là où il n'y a qu'un rendu manquant.
+
+Vérifié en exécution, sur les **deux** formulaires (ajout et modification d'un numéro) : bouton
+grisé à champ vide, dégrisé dès la première frappe, regrisé si l'on efface, et le clic — sans
+`Entrée` — crée puis renomme bien le numéro.
 
 617 tests au vert (618 avant : le test du découpage des unes n'a plus d'objet).