nx_tls13_server_session_emit_hrr.nx

nx_tls13_server_session_emit_hrr.nx -- server-side HelloRetryRequest emitter (RFC 8446 §4.1.4). HRR is sent when the client's ClientHello did NOT carry a key_share for a group the server supports, but DID list such a group in supported_groups. On the wire HRR is formatted IDENTICALLY to a ServerHello, with two differences: 1. Random is the fixed magic value SHA-256("HelloRetryRequest") (per RFC 8446 §4.1.3) -- supplied by tls13_hrr_magic_random. 2. The key_share extension body is JUST the 2-byte selected_group (NamedGroup) the server wants -- no actual key_exchange entry. This server supports exactly one group (X25519), so HRR always selects NG_X25519; the client then re-sends ClientHello2 with an X25519 key_share and the handshake proceeds normally. Transcript ordering (RFC 8446 §4.4.1, the HRR special case): 1. recv_ch feeds ClientHello1 into the transcript. 2. caller calls nx_tls13_transcript_replace_with_hrr (CH1 -> synthetic message_hash record). 3. THIS step feeds the HRR handshake body into the transcript. 4. recv_ch (CH2) feeds ClientHello2 in. So this emitter updates the transcript with the HRR body and the caller MUST have already done the replace_with_hrr in step 2. State: requires SSTATE_INIT (we are between CH1 and CH2; recv_ch returned NEED_HRR without advancing state). Does NOT advance state -- recv_ch(CH2) advances INIT -> CH_RECEIVED next. Per Cardinals 9 (single-responsibility), 22 (composition only): reuses tls13_ext_emit_supported_versions_server + tls13_hrr_magic_random. license_tier: ORIGINAL genealogy_id: international-research-sources/ietf/rfc_8446 lineage_id: nishi_tls13_server_session_emit_hrr_q1