Fiabilise le core et met à jour les dépendances

[Lramelot]

Part de #212 (chore/consolidate-core), dont elle contient les commits, et la complète : bugs trouvés en relecture, durcissement du démarrage, et reprise des mises à jour Renovate/Dependabot en attente. Si cette PR est fusionnée, #212 l'est avec.

Bug bloquant en prod

bootstrap/validate-env-vars.mjs a été renommé en .ts dans #212, mais le CMD du Dockerfile lance toujours le .mjs : le conteneur de prod s'arrête dès le démarrage. Le script start dépendait en plus de tsx, absent de l'image.

• Node 24 exécute le .ts nativement, le CMD et start l'utilisent.
• Le job docker du CI ne faisait que construire les images. Il les démarre maintenant : migrator sur un Postgres vierge, puis le bot avec un faux token, qui doit aller jusqu'au contrôle du token Discord.

Corrections du core

• Synchro des commandes : un serveur que le bot a quitté est ignoré au lieu de faire échouer toute la synchro.
• onInstall / onUninstall s'exécutent avant les appels à Discord. Avant, un hook en erreur laissait les commandes créées alors que le module restait désactivé.
• Interactions :
  • un bouton d'un module désactivé répond un message ;
  • un bouton en erreur répond une erreur ;
  • si tout le traitement échoue (base indisponible, config illisible), l'utilisateur reçoit un message dans sa langue au lieu de « L'application n'a pas répondu ».
• Démarrage :
  • handlers unhandledRejection / uncaughtException ;
  • arrêt qui ne s'exécute qu'une fois ;
  • écouteurs branchés avant la synchro des commandes ;
  • un module dont le onLoad échoue est retiré complètement ;
  • le processus s'arrête si le core ne se charge pas, pour que Docker le redémarre.
• L'intent Guilds déclaré par le core n'était jamais demandé : index.ts ne collectait les intents que des modules.
• Une commande ou un customId déclaré par deux modules est signalé au démarrage.
• Les écritures de config d'un même serveur passent l'une après l'autre : deux sauvegardes simultanées ne s'écrasent plus.
• Limite de 25 options de Discord respectée dans l'autocomplétion de /config (qui filtre aussi sur la saisie) et dans le menu de réinitialisation.
• Après un retour du bot sur un serveur, la version du module est mise à jour une fois ses commandes réinstallées.
• jd4h : le score qu'un admin peut fixer est plafonné à 1 milliard, pour éviter le dépassement de capacité en base au point suivant.

Exploitation

• L'état d'activation des modules est mis en cache (plus de requête SQL par message et par module) ; le cache est vidé à chaque écriture.
• Logs en JSON avec le niveau info par défaut en prod, logs lisibles avec le niveau debug en dev. pino-pretty passe en devDependency et LOG_LEVEL est transmis par compose.prod.yaml.

Dépendances

Reprend les PR #215, #158, #179, #175, #156 (actions et outils mise), ainsi que #97 (TypeScript 6), #216 (oxfmt 0.71), #160, #214, #213 et #218 (lockfile). Renovate et Dependabot devraient fermer ces PR une fois celle-ci fusionnée.

Vérifications

• pnpm build, tsc --noEmit, oxlint, oxfmt, et les 287 tests passent. Pour chaque correction testée, le test a été vu rouge sans le correctif.
• pnpm dev démarre sur le serveur de dev sans warning : 3 modules, 4 commandes, rounds jd4h synchronisés.
• Le test de démarrage des images Docker du CI a été rejoué en local.

Pas encore vérifié contre Discord : les boutons et commandes n'ont pas été cliqués, seul le démarrage l'a été. Les écritures de config simultanées sont testées avec une base simulée.

Point restant, hors de cette PR

Une commande renommée ou supprimée dans un module reste sur les serveurs : la mise à jour ne supprime que les commandes encore déclarées. La correction propre serait un enregistrement groupé par serveur, comme le fait déjà le mode dev, ce qui change le mode d'enregistrement en prod. À discuter.

🤖 Generated with Claude Code