L4.1 : expose query_type sur les outils de requête (D25)

QueryType était figé à 0 en dur dans executeQuery/executeScalarQuery : le
modèle Writing, opérationnel et mesuré, était inatteignable. Paramètre
query_type (défaut 0) sur call_query_api, query_wms_entities,
count_wms_entities — get_entity_schema et search_wms_data restent des
raccourcis Reading.

D3 reste la règle par défaut : la bascule est un opt-in, avertie dans les
descriptions d'outils (statuts en énumérations en Writing). Garde de valeur
assertValidQueryType dans le code (le wrapper D23 ne valide pas les valeurs),
avant tout réseau. En query_type != 0, un nom inconnu du Metadata Reading
passe tel quel avec warning (allowUnknown du resolver) — conservé aussi dans
la réponse d'erreur si le WMS échoue ensuite. Acté en D25 ; CLAUDE.md nuancé,
L4.1 retiré de la ROADMAP (reliquat : exploration Metrics, rapport à part).

Vérifications rejouées via le protocole (LIMAGRAIN / LIMAGRAI2512) :
- call_query_api(Products, query_type:1, limit:1) -> success, 1 ligne,
  queryType:1 dans la réponse.
- call_query_api(Products, query_type:3) -> erreur structurée contenant
  'ApplicationMetricDataContext' ne contient pas de définition pour 'Products'.
- call_query_api(Products, query_type:7) -> erreur locale nommant les 4
  contextes, aucun [API] POST/GET dans stderr.
- query_wms_entities(Container, limit:1) sans query_type -> comportement
  inchangé (resolvedTableName Containers, Reading, pas de champ queryType).
- call_query_api(FooBar123, query_type:1) -> transmis tel quel (payload
  QueryType:1 Expression Context.FooBar123...), erreur WMS
  ApplicationWritingRepository + warning de résolution dans la réponse.
- count_wms_entities(Product, query_type:1) -> count 51145 (~51160).
Baseline : tools/list 23, resources 6, rejet D23 d'un paramètre inconnu OK.

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

ROADMAP.md

@@ -17,25 +17,13 @@ contient que ce qui reste à faire.
 Deux angles morts constatés le 24/08/2026, plus larges que les lots 2 et 3. Les
 chiffres ci-dessous sont mesurés sur le tenant `LIMAGRAI2512`.
 
-### L4.1 — Le modèle Writing est inatteignable
+### L4.1 (reliquat) — Explorer le contexte Metrics
 
-`QueryType` est figé à `0` (Reading) en dur dans `api-service.js`
-(`executeQuery` et `executeScalarQuery`). Or `QueryContextType` a **quatre**
-valeurs. Testées une à une :
-
-| Valeur | Contexte | Résultat sur `LIMAGRAI2512` |
-|---|---|---|
-| `0` | Reading | opérationnel (seul utilisé aujourd'hui) |
-| `1` | Writing | **opérationnel** — `Context.Products` répond |
-| `2` | DataWarehouse | **non configuré** : `Could not resolve serviceType 'IDataWarehouse…'` |
-| `3` | Metrics | contexte présent (`ApplicationMetricDataContext`), modèle non exploré |
-
-Exposer `query_type` sur les outils de requête, défaut `0`. Attention : D3 reste
-vrai — en Writing les champs de statut sont des **énumérations**, donc
-`== "Release"` échoue. La bascule doit être un choix explicite et documenté.
-
-Le contexte `Metrics` mérite une exploration à part : c'est probablement là que
-vivent les données agrégées produites par les jobs `MetricGatherer`.
+L'exposition de `query_type` est livrée (D25). Reste l'investigation : le
+contexte `Metrics` (`QueryType: 3`, `ApplicationMetricDataContext`) mérite une
+exploration à part — c'est probablement là que vivent les données agrégées
+produites par les jobs `MetricGatherer`. Livrable : un rapport, pas du code
+(même phase d'investigation que L4.4).
 
 ### L4.2 — Une seule application sur neuf est visible