L5.2 : plafonne la taille de reponse des trois outils de requete

Aucune borne de VOLUME n'existait sur query_wms_entities, call_query_api et
search_wms_data -- seulement une borne de LIGNES (MAX_QUERY_ROWS). Le modele
Writing serialise l'agregat complet (navigations, $id) : une seule ligne
Products y pese 95 288 caracteres, la ou la meme ligne Reading en fait ~4 500.
Toutes ces reponses depassaient le seuil de rejet du client MCP (D24), qui
renvoie un echec opaque plutot qu'un resultat partiel.

Plafond commun MAX_QUERY_RESPONSE_CHARS (defaut 25 000, meme ordre de grandeur
que MAX_LOG_SEARCH_CHARS), applique par src/services/response-limit.js : on
ecarte des LIGNES ENTIERES, jamais coupees au milieu, et on signale avec le
vocabulaire D24 (truncated / returned / omitted / hint). Le helper est partage
parce que les trois outils partagent le meme mecanisme -- ce que les mecanismes
de get_system_parameters et search_logs, eux, ne font pas. La recherche
dichotomique evite 200 reconstructions d'une charge utile de ~1 Mo.

Mesures avant/apres (protocole, LIMAGRAIN, longueur de content[0].text) :

  query_wms_entities Products limit 200   957 234 -> 24 432
    count 200, returned 5, omitted 195, truncated
  search_wms_data "PAL"                   847 543 -> 22 992
    totalFound 150, returned 4, omitted 146 ; reparti en tourniquet :
    Products 2, Containers 1, Tasks 1 -- sans quoi Products, en tete,
    consommerait tout le budget et les deux autres reviendraient a zero
    resultat sans que rien ne le dise
  call_query_api Products query_type 1      95 288 -> 738
    cas limite : returned 0, omitted 1, truncated, hint expliquant le
    volume Writing et renvoyant vers Reading

Sous le plafond, rien ne change -- verifie identique OCTET POUR OCTET contre
la version precedente :

  query_wms_entities Container limit 1     4 476 -> 4 476
  call_query_api Products limit 2          9 671 -> 9 671
  get_entity_schema Container             11 172 -> 11 172
  search_wms_data sous plafond            11 767 -> 11 767
  count_wms_entities Products                120 -> 120 (non concerne)

MAX_QUERY_ROWS et les limites par defaut des outils sont inchanges : le
correctif est le bornage signale, pas une reduction silencieuse. L'avertissement
de volume rejoint la description du parametre query_type (D25) de
query_wms_entities et call_query_api, pas celle de count_wms_entities dont la
reponse est un scalaire.

Baseline preservee : 23 outils, 6 resources.

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

DECISIONS.md

@@ -465,8 +465,11 @@ Les mécanismes restent **volontairement locaux**, car ils diffèrent :
 on continue avec l'offset suivant) ; `search_logs` plafonne le volume
 (`MAX_LOG_SEARCH_CHARS`, défaut 25 000 caractères) en écartant des résultats
 **entiers** — jamais coupés au milieu de leurs lignes de contexte — et annonce
-en plus `omitted`, le compte écarté. Pas de helper partagé : le factoriser
-forcerait une abstraction commune à deux mécanismes qui n'en ont pas.
+en plus `omitted`, le compte écarté. Ces deux-là ne partagent pas de helper : le
+factoriser forcerait une abstraction commune à deux mécanismes qui n'en ont pas.
+Les **trois outils de requête**, eux, partagent le même mécanisme — ils
+partagent donc `src/services/response-limit.js` (voir ci-dessous). Le critère
+est le mécanisme, pas le nombre d'appelants.
 
 **Périmètre étendu (lot 5, 25/08/2026).** Trois familles d'outils dépassaient
 encore le seuil, toutes mesurées sur `LIMAGRAI2512` :
@@ -484,6 +487,41 @@ restent complètes dans chaque tranche ; seul `data` est fenêtré, et
 la seule différence avec l'ancienne réponse est ces trois champs de fenêtre
 (+65 caractères mesurés).
 
+`query_wms_entities`, `call_query_api` et `search_wms_data` **plafonnent leur
+volume** (`MAX_QUERY_RESPONSE_CHARS`, défaut 25 000 — même ordre de grandeur que
+`MAX_LOG_SEARCH_CHARS`) en écartant des **lignes entières**, via le helper
+commun `src/services/response-limit.js` (recherche dichotomique : ~8
+constructions au lieu de 200 retraits ligne à ligne sur des charges utiles de
+~1 Mo) :
+
+| Appel | Avant | Après |
+|---|---:|---:|
+| `query_wms_entities("Products", limit: 200)` | 957 234 | 24 432 (5 lignes sur 200) |
+| `search_wms_data("PAL")` | 847 543 | 22 992 (4 résultats sur 150) |
+| `call_query_api("Products", query_type: 1, limit: 1)` | 95 288 | 738 |
+
+Trois points de cadrage, tous vérifiés en exécution :
+
+- **Sous le plafond, rien ne change.** Aucun champ ajouté, réponse identique
+  **octet pour octet** (mesuré sur `query_wms_entities("Container", limit: 1)`,
+  `call_query_api`, `get_entity_schema`, `search_wms_data` sous plafond).
+  `MAX_QUERY_ROWS` et les limites par défaut des outils sont inchangés :
+  le correctif est le bornage signalé, pas une réduction silencieuse.
+- **Cas limite : une seule ligne dépasse le plafond.** Réel en Writing —
+  `call_query_api("Products", query_type: 1, limit: 1)` répond `returned: 0`,
+  `omitted: 1`, `truncated: true`, avec un hint qui explique le volume Writing
+  et renvoie vers Reading. C'est moins bon qu'un résultat, mais c'est mieux
+  qu'un rejet client opaque.
+- **`search_wms_data` répartit en tourniquet** les résultats gardés entre les
+  entités, et porte `returned`/`omitted` par entité en plus des totaux. Sans
+  cela, une entité volumineuse placée en tête consommerait tout le budget et
+  les suivantes reviendraient à zéro résultat sans que rien ne le dise —
+  exactement le faux négatif que corrige L5.4.
+
+`count_wms_entities` n'est pas concerné (`QueryScalarExecute` renvoie un
+scalaire), et son `query_type` ne porte donc pas l'avertissement de volume
+ajouté aux deux autres.
+
 Deux garde-fous de cadrage :
 
 - **Ne pas réduire les défauts existants** (`max_results` 50, `context_lines` 2)