docs: document MessagesService — single per-plugin YAML, defaults in jar

features.md: new section 8 "Service de messages" with the single-file model,
two-layer in-memory (jar defaults + user file), API examples,
template-override mechanism, and override-the-impl extension point.
Bootstrap section renumbered to 9.

decisions.md: new decision logging the choice of MessagesService design
(YAML, single per-plugin file, in-jar fallback for new keys, template
priority from the game plugin's own resource, programmatic set() for
dynamic cases).

README.md: feature list mentions externalized messages; diagrams index
adds messages-class-diagram.puml.

setup.md: new "Fichier messages" section explaining the file location,
how to seed it from a game plugin's bundled template, and the API for
hot reload / extras / programmatic set().

New diagram: docs/diagrams/messages-class-diagram.puml — MessagesService
interface, YamlMessagesService impl, link to CRCore, with explanatory
note on the two-source merge and template fallback at first boot.

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

docs/decisions.md

@@ -367,6 +367,36 @@ Format léger : une décision = un titre + contexte + choix + raison.
   bases existantes, ALTER TABLE manuel ou suppression du fichier
   (les bases d'event sont jetables).
 
+## 2026-06-09 — `MessagesService` : YAML externalisable, un seul fichier par plugin
+
+- **Choix** : nouveau module `fr.luc.crcore.message` avec une interface
+  `MessagesService` et une impl `YamlMessagesService`. Toutes les chaînes
+  utilisateur des commandes built-in passent par ce service.
+- **Modèle « un seul fichier par plugin »** :
+  - Defaults CR-Core embarqués dans le jar à
+    `resources/crcore-messages.yml` — **jamais écrits sur disque**, juste
+    chargés en mémoire comme couche de fallback.
+  - Fichier user unique :
+    `<plugin-dataFolder>/<plugin-name-lowercase>-messages.yml`. Auto-créé
+    au premier `enable()` à partir du template du plugin de jeu s'il en
+    bundle un sous le même nom, sinon à partir des defaults CR-Core.
+  - Lecture : le fichier user écrase les defaults sur les mêmes clés ;
+    une clé manquante retombe automatiquement sur le default CR-Core (donc
+    une future release CR-Core qui ajoute une clé marche sans intervention
+    admin).
+- **Pourquoi un seul fichier** : (1) UX admin — il édite un fichier, pas
+  deux ; (2) le plugin de jeu peut pré-remplir le template avec ses
+  overrides + ses propres messages en bundlant simplement son fichier
+  homonyme dans les ressources ; (3) zéro maintenance pour les clés
+  inchangées — elles restent en jar.
+- **Substitution** : placeholders `{name}` style, varargs key/value,
+  codes couleur `&` traduits automatiquement.
+- **Override de l'impl** : `CRCore.buildMessagesService()` protected,
+  surchargeable pour passer à une autre source (DB, microservice, etc.).
+- **Pas de programmatique-only** : le service supporte `set(key, template)`
+  en mémoire pour des cas dynamiques, mais le mode principal reste le
+  YAML pour l'éditabilité par l'admin sans recompile.
+
 ## 2026-06-09 — Toutes les commandes "chef" deviennent admin (révision)
 
 - **Révision** de la décision "Refonte permissions + modèle admin/chef/joueur"