fix: corriger ORDER BY ml_detected_anomalies dans le schéma de base

CH 24.8 refuse MODIFY ORDER BY sur des colonnes existantes (erreur BAD_ARGUMENTS 36).
La migration 01 ne pouvait donc pas corriger l'ORDER BY en post-init.

Correctif :
- 06_ml_tables.sql : ORDER BY (src_ip) → ORDER BY (src_ip, ja4, host, model_name)
  + TTL 30j → 7j (cohérent avec l'architecture documentée)
- 01_ttl_adjustments.sql : supprime le MODIFY ORDER BY impossible, conserve
  uniquement les MODIFY TTL (valides pour les déploiements existants)

Résultat : make init-stack sans aucun ⚠ ni ✗

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

services/correlator/sql/migrations/01_ttl_adjustments.sql

@@ -62,14 +62,11 @@ ALTER TABLE ja4_processing.agg_host_ip_ja4_1h
 ALTER TABLE ja4_processing.agg_header_fingerprint_1h
     MODIFY TTL window_start + INTERVAL 7 DAY;
 
--- ml_detected_anomalies — CRITIQUE : corriger ORDER BY (était (src_ip), causait une
--- déduplication agressive — une seule ligne conservée par IP au lieu de src_ip+ja4+host+model)
--- Note : ALTER TABLE ... MODIFY ORDER BY nécessite ClickHouse >= 22.6
---   Si la version est antérieure, recréer la table via deploy_views.sql.
-ALTER TABLE ja4_processing.ml_detected_anomalies
-    MODIFY ORDER BY (src_ip, ja4, host, model_name);
-
 -- ml_detected_anomalies — TTL 7 jours (était 30 jours, déjà corrigé en 7j pour certains)
+-- Note : MODIFY ORDER BY (src_ip, ja4, host, model_name) ne peut PAS être appliqué
+-- sur ClickHouse 24.8 car ja4/host sont des colonnes existantes (erreur BAD_ARGUMENTS 36).
+-- Le correctif est dans le schéma de base (06_ml_tables.sql) — ORDER BY corrigé à la
+-- création. Pour les déploiements existants avec l'ancien ORDER BY, recréer la table.
 ALTER TABLE ja4_processing.ml_detected_anomalies
     MODIFY TTL detected_at + INTERVAL 7 DAY;
 

shared/clickhouse/06_ml_tables.sql

@@ -13,8 +13,11 @@
 -- -----------------------------------------------------------------------------
 -- ml_detected_anomalies — anomaly detections above threat threshold
 --
--- Déduplication : ReplacingMergeTree(detected_at) sur ORDER BY (src_ip)
+-- Déduplication : ReplacingMergeTree(detected_at) sur ORDER BY (src_ip, ja4, host, model_name)
---   → conserve la détection la plus récente par IP.
+--   → conserve la détection la plus récente par (IP, empreinte, hôte, modèle).
+--   Note : ORDER BY (src_ip) seul causait une déduplication agressive (une seule
+--   ligne conservée par IP). Corrigé directement dans ce fichier (CH 24.8 ne permet
+--   pas MODIFY ORDER BY sur des colonnes existantes via ALTER TABLE).
 -- PARTITION BY : élagage journalier (les requêtes 24h/7j ignorent les vieilles
 --   partitions sans lire aucune donnée).
 -- INDEX idx_detected_at : skip des granules 8192 lignes hors de la plage
@@ -60,8 +63,8 @@ CREATE TABLE IF NOT EXISTS ja4_processing.ml_detected_anomalies
 )
 ENGINE = ReplacingMergeTree(detected_at)
 PARTITION BY toYYYYMMDD(detected_at)
-ORDER BY (src_ip)
+ORDER BY (src_ip, ja4, host, model_name)
-TTL detected_at + INTERVAL 30 DAY
+TTL detected_at + INTERVAL 7 DAY
 SETTINGS
     index_granularity  = 8192,
     ttl_only_drop_parts = 1;  -- supprime la partition entière à expiration (plus efficace)
@@ -121,14 +124,12 @@ SETTINGS
 -- -----------------------------------------------------------------------------
 -- view_ip_recurrence — récurrence des détections par IP
 --
--- Agrège ml_detected_anomalies (ORDER BY src_ip) pour obtenir le profil
+-- Agrège ml_detected_anomalies (ORDER BY src_ip, ja4, host, model_name)
--- de récurrence de chaque IP détectée.
+-- pour obtenir le profil de récurrence de chaque IP détectée.
 --
--- Optimisation : avec PARTITION BY toYYYYMMDD(detected_at) (ajouté en P1),
+-- Optimisation : avec PARTITION BY toYYYYMMDD(detected_at), chaque GROUP BY
--- chaque GROUP BY src_ip bénéficie de l'élagage de partitions si la vue est
+-- src_ip bénéficie de l'élagage de partitions si la vue est filtrée par date
--- filtrée par date en amont (les routes filtrent généralement sur 30 jours max).
+-- en amont (les routes filtrent généralement sur 30 jours max).
--- Le ORDER BY (src_ip) garantit que le GROUP BY src_ip lit des données
--- contiguës en mémoire (co-localisation des lignes d'une même IP).
 -- -----------------------------------------------------------------------------
 CREATE OR REPLACE VIEW ja4_processing.view_ip_recurrence AS
 SELECT