nx_hkdf384_gate.nx

nx_hkdf384_gate.nx -- the SHA-384 half of HKDF, proven without inventing a vector. WHY THIS EXISTS. Our sovereign TLS client offers 0x1302 (AES-256-GCM-SHA384) and then cannot derive its keys: the whole 1.3 key schedule runs on SHA-384 for that suite, while nx_hkdf.nx was SHA-256 by construction. Servers that PREFER 0x1302 were unreachable and the failure surfaced as a bare handshake verdict=5 three layers from the cause. Every primitive already existed (hmac_sha384, sha384_digest, nx_aes256_gcm_seal/open) -- the gap was wiring, the banked adoption-gap class. This gate covers the hash-parameterized hkdf_extract_h/expand_h. ★THE HONEST PROBLEM THIS GATE SOLVES: RFC 5869 publishes vectors for SHA-256 and SHA-1 ONLY. There is NO published HKDF-SHA-384 test vector. Writing down whatever our code prints and calling it a KAT is fabrication wearing a citation -- the exact "invented golden" class already banked in this estate. So SHA-384 is proven by DEFINITIONAL IDENTITY instead: RFC 5869 defines Extract as HMAC(salt, IKM) and Expand's T(1) as HMAC(PRK, info || 0x01), and this gate recomputes both sides independently with hmac_sha384 and demands bit equality. A definition is re-derivable by anyone; a screenshot of our output is not. license_tier: ORIGINAL No hw writes (Rule 26).