nx_hmac_extvec_gate.nx

nx_hmac_extvec_gate.nx -- HMAC-SHA-256 vs RFC 4231, ALL SEVEN published test cases. SUPERSEDES the single-case version. Going from 1 vector to 7 matters because the cases are deliberately chosen by the authority to hit DIFFERENT code paths, and the ones I was NOT running are the interesting ones: case 3 uses a 50-byte repeated data block, cases 6 and 7 use a 131-BYTE KEY (longer than the 64-byte SHA-256 block, so the key must be HASHED first), and case 5 publishes a TRUNCATED 128-bit MAC. ★A gate that ran only case 1 would never touch the key-longer-than-block branch -- the single most commonly botched part of HMAC. Running one vector from a seven-vector suite is not "validated against RFC 4231"; it is validated against one line of it. ⚠VARIABLE-LENGTH FIELDS, HANDLED BY TERMINATOR NOT BY LENGTH. Key/Data lengths differ per case and their annotations are inconsistent -- "(20 bytes)" for keys but ("Hi There") for data -- so a length cannot be read uniformly. Instead the hex run is read until the first `(`, which terminates both forms. ⚠THE MAC HAS NO `(` TERMINATOR and case 5's is TRUNCATED to 16 bytes, so it is read as hex pairs until a pair is not both-hex, capped at 32. That correctly stops at the section heading that follows -- note "4.3." begins with '4', a HEX DIGIT, and is only rejected because '.' is not: the PAIR rule saves this, a single-nibble rule would have swallowed it. Construction unchanged: no expected value in this source, document pinned to a socket-time digest, every key/data/MAC read from that pinned document, and a completeness check that refuses GREEN below 7. license_tier: ORIGINAL expect_exit: 0