feat: SQLite persistence, default /core commands, Bukkit events, bootstrap

CRCore bootstrap class: one-line setup for game plugins (new CRCore(this).enable()).
Wires SQLite, services with event firing, and the /core command tree.

SQLite layer (fr.luc.crcore.database): Database wrapper exposing execute/update/
queryOne/query plus a fluent TableBuilder. ColumnType enum, RowMapper interface,
DatabaseException. Game plugins create their own tables in 2 lines via
db.table("foo").ifNotExists().column(...).create().

Repositories: SqliteTeamRepository and SqlitePlayerProfileRepository extend their
InMemory counterparts (write-through cache). 5 internal tables prefixed crcore_.

Command framework refactored for nested sub-commands: subcommand storage moved
from BaseCommand to AbstractCommand, recursive dispatch() and tabComplete(),
replaceSubCommand() for plugin overrides.

Default /core team commands (13 leaf sub-commands): create, delete, add, remove,
join, leave, info, list, transfer, visibility, score, top, setspawn. Each in its
own class under fr.luc.crcore.command.builtin.team, fully substitutable.

Bukkit events: 9 team events (Create/Dissolve/MemberAdd/MemberRemove/PlayerJoin/
LeadershipTransfer/VisibilityChange/ScoreChange/SpawnPointChange) + 3 player
events (ProfileCreate/Delete/ScoreChange). All post-only, non-cancellable.
BukkitEventFiringTeamServiceImpl and BukkitEventFiringPlayerProfileServiceImpl
override the on* hooks to call Bukkit.getPluginManager().callEvent.

JavaDoc on all new public classes and key existing ones. docs/, GEMINI.md and
PUML diagrams synced: new sections (built-in commands, events, database,
bootstrap), 4 new diagrams (builtin-commands, events, database, bootstrap-
sequence), and 7 new architecture decisions logged.

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

GEMINI.md

@@ -8,41 +8,59 @@
   être lue depuis `docs/` et écrite dans `docs/`.
 - Avant d'implémenter, vérifier ce qui est consigné dans `docs/`.
 - Toute nouvelle information donnée par l'utilisateur va dans le fichier adapté :
-  - `docs/features.md` — domaines fonctionnels (team, command, …)
+  - `docs/features.md` — domaines fonctionnels (team, player, commandes built-in, events, database)
   - `docs/decisions.md` — décisions techniques / architecturales
   - `docs/setup.md` — installation, build, intégration côté plugin de jeu
   - `docs/README.md` — vue d'ensemble et index
   - `docs/diagrams/*.puml` — diagrammes (classe / séquence / activité)
-- En cas de conflit code ↔ `docs/`, `docs/` fait foi : aligner le code, ou
-  mettre la doc à jour explicitement avec l'utilisateur.
+- En cas de conflit code ↔ `docs/`, `docs/` fait foi.
 
 ## Nature du projet
 
-**CR-Core** est une **librairie Java/Maven pure** — pas un plugin Bukkit. Elle
-fournit les briques réutilisables (domaine team, framework de commandes,
-abstractions communes) que chaque plugin de jeu (futur `CitesPlugin`, etc.)
-consomme en dépendance Maven.
+**CR-Core** est une **librairie Java/Maven** consommée par des plugins Bukkit
+("plugins de jeu"). Pas de `plugin.yml` côté core — c'est le plugin de jeu
+qui en a un et qui instancie {@code CRCore} dans son {@code onEnable()}.
 
 - **Nom** : CR-Core (artifactId Maven : `CR-Core`)
-- **Type** : librairie (`jar`) — pas de `plugin.yml`, pas de `JavaPlugin`
-- **Cible runtime** : serveur Paper/Spigot 1.16.5 (le plugin de jeu downstream
-  est responsable du `plugin.yml` et de l'enregistrement des commandes)
+- **Type** : librairie (`jar`)
+- **Cible runtime** : serveur Paper/Spigot 1.16.5
 - **Build** : Maven, Java 16
 - **Package racine** : `fr.luc.crcore`
+- **SQLite** : `org.xerial:sqlite-jdbc` (compile scope)
+
+## Domaines
+
+- `fr.luc.crcore.common` — abstractions partagées (`Identifiable`, `Named`,
+  `ScoreHolder`, `AbstractEntity`, `Repository<T>`)
+- `fr.luc.crcore.team` — équipes : visibilité (PUBLIC/PRIVATE), membres,
+  leader, scores nommés, classements, point de spawn. Sous-package `event/`
+  pour les évènements Bukkit.
+- `fr.luc.crcore.player` — profils joueurs : scores nommés, classements
+  individuels. Sous-package `event/`.
+- `fr.luc.crcore.command` — framework de commandes (nested sub-commands,
+  arguments typés, tab-complete). Sous-package `builtin/` pour les commandes
+  par défaut `/core team ...`.
+- `fr.luc.crcore.database` — wrapper SQLite minimaliste (`Database`,
+  `TableBuilder`, `RowMapper`).
+- `fr.luc.crcore.CRCore` — point d'entrée bootstrap (instancié en une ligne
+  par le plugin de jeu).
 
 ## Principe : simple par défaut, overridable partout
 
-Toutes les classes du noyau sont conçues pour être étendues. Les services
-fournissent une implémentation "tout faite" (ex. `TeamServiceImpl`), mais chaque
-étape importante est exposée via une méthode `protected` (`newTeam`,
-`validateName`, `onAfterCreate`, …) qu'une sous-classe peut overrider.
+Chaque service expose des **hooks `protected`** que les plugins de jeu peuvent
+overrider :
+- factories (`newTeam`, `newRanking`, `newProfile`)
+- validations (`validateName`, `validateJoinable`, …)
+- post-hooks (`onAfterCreate`, `onMemberAdded`, `onScoreChanged`, …)
+
+Chaque commande built-in (`TeamCreateSubCommand`, etc.) est elle aussi
+substituable par nom via `replaceSubCommand(...)`.
 
 **Règles** :
-- Pas de `final` sur les classes du noyau, sauf raison forte.
-- Méthodes-clés en `protected` (pas `private`) pour permettre l'override.
+- Pas de `final` sur les classes du noyau.
+- Méthodes-clés en `protected` (pas `private`).
 - Hooks `onBefore...` / `onAfter...` partout où ça a du sens.
-- Factories (`newTeam`, `newMember`, …) pour permettre de substituer des
-  sous-classes sans réécrire le service.
+- Factories pour permettre les sous-classes.
 
 ## Workflow attendu
 
@@ -54,6 +72,7 @@ fournissent une implémentation "tout faite" (ex. `TeamServiceImpl`), mais chaqu
 ## Conventions de code
 
 - Code (classes, méthodes, attributs, variables) en **anglais standard**.
-- Messages joueur et documentation en français.
+- Messages joueur et documentation en **français**.
+- JavaDoc en français sur les classes publiques et les méthodes non triviales.
 - Séparation stricte : `interface`, `enum`, `abstract class`, `class` concrète,
   `exception` — chacun dans son fichier.