nx_tls13_server_session_emit_certificate.nx

nx_tls13_server_session_emit_certificate.nx -- stone 6.5 (final core TLS server stone). Emits the server Certificate handshake message: caller supplies pre-encoded DER cert bytes, substrate wraps them in the TLS 1.3 Certificate structure + AEAD-encrypted record. Per RFC 8446 §4.4.2 Certificate message body: opaque certificate_request_context<0..2^8-1>; // server: empty CertificateEntry certificate_list<0..2^24-1>; CertificateEntry: opaque cert_data<1..2^24-1>; // DER cert Extension extensions<0..2^16-1>; // empty for v1 Wire layout (one cert, no extensions): HT_CERTIFICATE (0x0b) (1 byte) u24 body_len (3 bytes) u8 cert_request_ctx_len = 0 (1 byte) u24 cert_list_len (3 bytes) u24 cert_data_len (3 bytes) cert_data (cert_data_len bytes) u16 extensions_len = 0 (2 bytes) Caller responsibility: - Supply a valid DER-encoded X.509 cert (from ACME, self-signed test cert, etc.). Substrate does NOT validate the DER -- it just wraps the bytes. Per [[feedback-no-third-party-trust- native-or-nothing]]: future stone can compose nx_x509 + nx_acme to produce the cert bits-up. Substrate provides: WIRE FORMAT. Operator provides: cert bytes. Together = real-world-client-acceptable server. State machine: requires EE_SENT (set by derive_hs_secrets after emit_ee actually emits). Wait -- the existing flow sets state EE_SENT after derive_hs but PRE-emit_ee; emit_ee then sets CERT_SENT. This stone, IF inserted, would run AFTER emit_ee, so require CERT_SENT and advance to ... a new state.