feat(wiki-glossary): Hook optionnel d'extraction de glossaire depuis des sources structurées

Provenance : adapté depuis fyl-guidelines#12 (généralisé — l'original était couplé à des sources SQL/OpenAPI spécifiques à un fork). Fait partie de l'EPIC #3.

Contexte

Quand un fork dispose de sources déjà structurées et machine-lisibles (schéma de base de données, spec OpenAPI, enum de code, etc.), les faits qu'elles contiennent sont aujourd'hui retapés de mémoire par l'agent ingest en prose — source classique de divergence terminologique (le README le liste : "terminologie inconsistante" est un des checks de consolidate).

Détails d'implémentation

• Introduire un fichier wiki/shared/glossary.json optionnel, schéma d'entrée type :

{
  "term_id": {
    "type": "enum|entity|...",
    "aliases": ["..."],
    "description": "...",
    "source": "raw/....#Lx",
    "status": "auto-extracted",
    "deprecated_aliases": []
  }
}

• Fournir une interface de parseur pluggable (pas un LLM) que chaque fork peut implémenter pour ses propres sources structurées (schéma SQL, OpenAPI, JSON Schema, ou autre selon le projet) — le template ne fournit qu'un exemple de référence, pas une intégration figée à une stack.
• Toute entrée générée par un parseur porte status: "auto-extracted" — jamais l'agent LLM n'est l'auteur de ces valeurs.
• Pré-requis pour la sous-issue "Workflow de dédoublonnage".

Critères d'acceptation

• Schéma glossary.json documenté dans docs/
• Interface de parseur pluggable définie (contrat d'entrée/sortie), avec un exemple de référence
• consolidateur-wiki/futur glossaire-curateur sait lire glossary.json si présent
• Documentation explicite : ce mécanisme est optionnel, un fork sans source structurée n'est pas impacté