docs(netcode): findings AES-GCM — le client ferme systématiquement (plaintext bClose) après notre réponse au Hello ; pistes restantes

NETCODE-RND.md

@@ -137,3 +137,29 @@ keyé par la PSK** (SetEncryptionData/EnableEncryption d'UE) plutôt que du DTLS
 **Acquis réutilisables :** on passe le handshake + le Hello + l'EncryptionAck est accepté ;
 la PSK par user_id est branchée bout-en-bout (Vault → env → serveur). Le blocage net =
 chiffrement de la voie serveur post-ack.
+
+## MAJ (2026-07-16, nuit) — tentative AES-256-GCM keyé par la PSK
+
+Implémenté `AesGcmHandlerComponent` (`System.Security.Cryptography.AesGcm`, format
+`[IV 12o][ciphertext][tag 16o]`), activé après l'EncryptionAck (ack en clair → activation →
+Challenge chiffré). Corrigé aussi l'ordre du pipeline : **Incoming doit itérer en sens
+INVERSE d'Outgoing** (`PacketHandler.Incoming_Internal`) — sinon, avec 2 composants actifs
+(stateless + AES), le stateless tente de parser des octets chiffrés. (Les deux étaient en avant ;
+n'avait jamais compté car un seul composant actif jusqu'ici.)
+
+**Observé (test live) :** notre Challenge part bien chiffré (`[AES] Outgoing 30o→58o`), mais le
+client répond **toujours** par un **paquet plaintext de ~18 o** de structure constante
+(`…41 00 XX FF 5F 00 00 0C`) = un **`bClose` du canal de contrôle**, jamais rien qui ressemble
+à de l'AES (haute entropie ≥28o). **Le client ne chiffre jamais son côté.**
+
+**Conclusion :** quelle que soit notre réponse au `Hello` (challenge clair, chiffré AES, ou
+tentative DTLS), le client **ferme systématiquement le canal de contrôle en clair** juste après.
+L'AES-GCM tel qu'implémenté ne le fait pas basculer en chiffré. Pistes restantes (deep RE, non
+tranchées) : (a) framing AES-GCM exact d'UE (schéma d'IV/nonce, AAD, position) ≠ notre IV aléatoire
+préfixé ; (b) c'est bien du DTLS-handshake et le client attend un ServerHello DTLS ; (c) notre
+réponse au Hello est incomplète (ordre/contenu des NMT) indépendamment du chiffrement.
+Chaque test = ~4 min (CI + redeploy). Bugs serveur secondaires à corriger : `ConditionalCleanUp`
+(stub) + `ArgumentOutOfRangeException` quand on vide un paquet trop court.
+
+**Décision : checkpoint.** Tout est commité/documenté. La suite = RE netcode profonde multi-session ;
+et même résolue, ce n'est que le login — la simulation gameplay reste hors de portée réaliste.