docs(netcode): VERDICT — le client n'entame jamais son handshake DTLS (résolution de clé côté client), mur dur indépendant du serveur

NETCODE-RND.md

@@ -191,6 +191,29 @@ de clé côté client** (le vrai client shipping attend peut-être la clé de SO
 non émulé — ou dérivation/Identifier différents), pas notre framing DTLS. C'est potentiellement un
 mur dur (dépend du backend réel du client).
 
-**Test informé en cours** : `EncryptionAck` seul (clair, sans payload) + DTLS **accept** (attente) +
-**PAS de Challenge** → observer si le client envoie enfin un ClientHello `16 fe fd`. Si oui → progrès ;
-si non → mur « résolution de clé côté client ».
+**Test informé RÉALISÉ (2026-07-17)** : `EncryptionAck` seul (clair, sans payload) + DTLS **accept** +
+**PAS de Challenge**. **Résultat : le client n'envoie TOUJOURS pas de ClientHello** (zéro `16 fe fd`
+dans les datagrammes bruts) et ferme avec le `bClose` plaintext habituel.
+
+## VERDICT (mur confirmé) — résolution de clé CÔTÉ CLIENT
+
+Le blocage n'est **pas** notre framing serveur (DTLS ou AES) : le client **n'entame jamais son
+handshake DTLS**. Séquence définitive observée, quel que soit ce qu'on renvoie :
+`stateless OK → NMT_Hello (clair) → notre NMT_EncryptionAck → client ferme (bClose), pas de ClientHello`.
+
+D'après la recherche du flux UE : le ClientHello n'est émis que si le client, dans
+`ReceivedNetworkEncryptionAck`, **résout une `FEncryptionData` valide et appelle `EnableEncryption`
+côté client**. Ici il ne le fait pas → il ferme. On **ne peut pas forcer** ça depuis le serveur.
+
+Cause la plus probable : le vrai client shipping attend sa clé/identité **de SON backend**
+(réponse matchmaking/PlayFab), non émulée — ou une dérivation/`Identifier` qu'on ne fournit pas au
+bon endroit. La PSK a été récupérée (dump mémoire) mais ça ne suffit pas : c'est la **décision
+client d'activer le chiffrement** qui manque, et sa logique vit dans le binaire packé.
+
+**Pour aller plus loin il faudrait** : RE de la fonction `ReceivedNetworkEncryptionAck`/résolution de
+clé du client (dans le `.text` déchiffré, même méthode que pour la PSK) pour savoir **d'où** il attend
+sa clé, puis la lui fournir (probablement côté backend rd2). Chantier RE profond, incertain.
+
+**Statut : mur dur, checkpoint.** Acquis solides et réutilisables : handshake + Hello + EncryptionAck ;
+serveur DTLS-PSK ET AES-GCM implémentés ; ordre pipeline corrigé (Incoming inverse d'Outgoing) ;
+flux UE documenté. Le verrou restant dépend du client, pas du serveur.