feat: configurable broadcasts + /core reload

New fr.luc.crcore.broadcast module:
- BroadcastAudience enum (NONE, LEADER, TEAM, ADMIN, ALL).
- BroadcastContext (fluent: team + involvedPlayerId + placeholders).
- BroadcastService interface + YamlBroadcastService impl.
- CRCoreBroadcastListener (Bukkit listener) wires the 12 native events
  (9 team + 3 player) to broadcasts.broadcast(eventKey, ctx).

Same single-per-plugin file pattern as messages:
<plugin-dataFolder>/<plugin-name-lowercase>-broadcasts.yml. Defaults
bundled at resources/crcore-broadcasts.yml, copied on first boot (game
plugin's own resource of the same name takes priority as the template).
In-memory fallback so new CR-Core keys work without admin edit.

Routes (who) vs templates (what) are separated: broadcasts.yml lists
audiences per eventKey, messages.yml contains the templates under keys
<eventKey>.broadcast. Admin can change either independently.

12 new *.broadcast keys added to crcore-messages.yml with sensible
French defaults and color codes. Listener injects standard placeholders
(name, team_name, tag, color, visibility, player, new_leader,
old/new_value, etc.).

ADMIN audience resolved via crcore.broadcast.admin permission. Multi-
audiences via YAML list (e.g., [TEAM, ADMIN]); union of resolved
players, no duplicate.

New /core reload subcommand (permission crcore.reload) hot-reloads
both messages and broadcasts from disk without restart.

CRCore: protected buildBroadcastService() override point, getter
broadcasts(), wire of CRCoreBroadcastListener at enable(). CoreCommand
constructor extended to take BroadcastService, registers the reload
subcommand.

Docs/features.md: new section 9 "Service de broadcasts". docs/setup.md:
updated to mention both YAML files. decisions.md logs the routes-vs-
templates split, the audience model, and the reload semantics.
New diagram broadcasts-class-diagram.puml. README updated.

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

docs/setup.md

@@ -265,6 +265,24 @@ CitesPlugin/                                 # dossier IntelliJ (renommer plus t
             └── SqlitePlayerProfileRepository.java
 ```
 
+## Fichiers de config générés au premier `enable()`
+
+Au premier démarrage, CR-Core crée DEUX fichiers dans le dataFolder :
+
+| Fichier | Rôle |
+|---|---|
+| `<plugin-name-lowercase>-messages.yml` | Templates de tous les messages (commandes + broadcasts) |
+| `<plugin-name-lowercase>-broadcasts.yml` | Routes : qui reçoit quel event |
+
+Les deux suivent le même pattern : si ton plugin de jeu bundle un fichier
+au même nom dans ses ressources, c'est lui qui sert de template initial à
+la place des defaults CR-Core. Les defaults restent en mémoire en
+fallback — donc les clés non présentes dans le fichier user marchent quand
+même.
+
+Hot reload : `/core reload` (permission `crcore.reload`) relit les deux
+fichiers sans restart.
+
 ## Fichier messages
 
 Au premier `enable()`, CR-Core crée :