fix(editor): fire an input event when the generator fills the password

Assigning .value fires nothing, and the code called soDirtyCheck by hand - so the strength bar, which listens to input, stayed frozen on the previous password. Dispatching the event covers every listener on the field instead of one named handler.

TEST_SCENARIOS.md

@@ -378,15 +378,17 @@ ou le déchiffrement.
 - **Bonus** : dump mémoire du renderer → `this_is_password` peut persister
   (strings V8, non corrigeable) ; c'est la **clé** qu'on a retirée du storage.
 
-### E6 · non-régression — les 4 exporteurs de clé marchent toujours
+### E6 · non-régression — les 4 exporteurs de clé marchent toujours ✅
 Après le retrait du cache sessionStorage, re-tester que ces flux (qui
 `exportKey` la clé) fonctionnent : **login**, **Quick Unlock**, **PIN**,
 **recovery redeem**, **change master password**.
 
-### E7 · non-régression — éditeur slideover après suppression du modal mort
+### E7 · non-régression — éditeur slideover après suppression du modal mort ✅
 Le générateur, les tags et la barre de force étaient partagés. Vérifier dans
 l'éditeur slideover : créer + éditer une entrée, ajouter/retirer des tags,
 **Generate → Use** insère le mot de passe, la barre de force réagit.
+- **Bug trouvé par ce test** : la barre restait figée sur le mot de passe précédent. Affecter `.value` en JavaScript **ne déclenche aucun événement** ; le code appelait `soDirtyCheck()` à la main, mais la barre de force écoute `input` et n'était donc jamais prévenue.
+- **Correctif** : émettre `new Event('input')` sur le champ plutôt que d'appeler un gestionnaire nommé. Tous les auditeurs du champ sont couverts, y compris ceux qu'on y branchera plus tard — c'est le même piège chaque fois qu'un bouton remplit un champ à la place de l'utilisateur.
 
 ---