fix: migration MCP SDK 2 et ontologies orphelines (v3.2.1)

[chrlesur]

Objet

La v3.2.1 corrige le nettoyage des ontologies S3 orphelines et migre vers le SDK officiel MCP 2.1.1, à la demande de Christophe. Les 40 outils, leurs arguments et les données existantes sont conservés.

Changements

• Nettoyage S3 limité aux ontologies non référencées, avec protection des mémoires legacy.
• Serveur MCPServer, transport Python httpx2/streamable_http_client et callback public de progression.
• Console admin branchée sur mcp.call_tool au lieu du registre privé du SDK.
• Limite HTTP explicitement dimensionnée pour les documents de 50 Mio encodés en base64 ; la valeur par défaut du SDK 2 était de 4 Mio.
• Dépendances Python figées dans requirements.lock, installation Docker sans upgrade pip non borné, contrôle des imports SDK 2 au build.

Validation

• Build Docker sans cache : PASS (Python 3.11, Linux arm64).
• Tests ciblés : 9/9 PASS sur le poste et dans Docker, dont 3 tests de stockage et 6 cas HTTP SDK 2.
• Protocoles legacy et 2026-07-28, permissions, cookie admin, erreurs, progression, requête de 5 Mio et rejet au-delà de la limite : PASS.
• Comparaison avec le service SDK 1 existant : les schémas d'entrée des 40 outils sont identiques.
• Client SDK 2 vers serveurs SDK 1 et SDK 2 : PASS ; client SDK 1 vers serveur SDK 2 : PASS.
• git diff --check : PASS.
• Le nettoyage réel du 30 août avait supprimé 5 ontologies orphelines, puis confirmé zéro résidu.

La clé LLMaaS a été renouvelée et la recette fonctionnelle ciblée a été exécutée avec succès ; la suite de recette globale n'a pas été rejouée. Voir les résultats et la réserve S3 ci-dessous. Avertissements de dépréciation des notifications de logs et de dépendances existantes, sans échec des tests.

Les environnements exécutant la CLI Python doivent réinstaller les dépendances (pip install -r requirements.txt -r requirements.lock). Aucun déploiement de production ni fusion effectués. Les travaux CLI Go/v3.3 sont exclus de cette PR.

Fixes #30
Fixes #31

Recette réelle après renouvellement de la clé — 31 août 2026

Serveur testé : image graph-memory:sdk2-v3.2.1, code applicatif 2906c3c, Python 3.11, MCP 2.1.1, sur un conteneur local temporaire. Clients : CLI Go 9eb85c7 et CLI Python SDK 2. Corpus synthétique isolé, aucun document métier utilisé.

19 contrôles fonctionnels réussis :

• LLM et embeddings : HTTP 200 après renouvellement de la clé.
• 3 fichiers Markdown/TXT/JSON ingérés ; un doublon local écarté. 14 entités et 15 relations extraites avant remplacement.
• Hashes, chemins sources, statuts durables et chunks d'embedding vérifiés.
• Recherche graphe : 8 résultats ; recherche vectorielle : 3 passages retrouvés avec leurs chemins sources.
• Deuxième passage : aucun upload, 4 fichiers ignorés comme inchangés.
• Idempotence serveur skipped, modification sans autorisation changed_skipped, remplacement explicite via Go sans doublon et checksum invalide rejeté.
• Cohérence avant nettoyage : 3/3 documents accessibles sur S3, aucun orphelin ni incohérence S3/Neo4j/Qdrant.

Réserve d'exploitation : des délais TLS/S3 intermittents ont été observés depuis Docker et depuis le poste. Le problème est aussi reproductible avec le serveur SDK 1 et avec deux versions de boto3 ; aucune dépendance applicative n'a été changée pour le masquer. L'appel MCP de nettoyage a dépassé le délai client de 120 secondes. Les logs confirment ensuite la suppression des quatre objets S3 ; un nettoyage ciblé du graphe a également été effectué. Vérification indépendante finale : zéro objet S3, zéro nœud Neo4j et aucune collection Qdrant pour la mémoire de recette.

Conteneur temporaire supprimé. Serveur habituel inchangé. Pas de fusion, tag ni déploiement de release. La revue requise et la vérification de stabilité S3 restent à traiter avant publication.