nx_h2_serve_multi.nx

nx_h2_serve_multi.nx -- TUTOR-BOOTSTRAP SCAFFOLD (Claude, authored under the B1 rung(6) PERSISTENT-MULTI-STREAM step of the R4-H2 HTTP/2-transport ladder), NOT credited as team self-authoring (back-fill via the emitter-of-emitters once the daemon-from-spec organ exists -- X-AUT-006c/e/f). THE PERSISTENT MULTI-STREAM ALPN-h2 SERVER CONNECTION-DRIVER organ (single responsibility: SERVE >1 REQUEST STREAM on ONE already-accepted, KEPT-ALIVE h2 connection over OUR sovereign TLS 1.3). This is the EVOLUTION of nx_h2_serve.nx h2_serve_connection, which serves exactly ONE stream then sends GOAWAY + closes (so each external curl --http2 GET needs a FRESH TCP connection; num_connects=1 per request). The persistent driver here: - does NOT send GOAWAY after each stream (GOAWAY ends the whole connection), - LOOPS reading TLS records, COMPACTING consumed frame bytes out of a bounded buffer (so the buffer survives many sequential requests), responding to EACH request HEADERS frame on ITS OWN client-chosen odd stream id (1,3,5,...), - stops when (a) the client closes the connection (read EOF -- the clean end of a sequential keep-alive burst), (b) the client sends GOAWAY, or (c) the served count reaches the caller's max_streams cap (honest backstop), and - sends ONE GOAWAY(last_stream_id) at the very end, then the LM-023 graceful shutdown(SHUT_WR)+drain so the peer reads every response (close-with-unread RX would RST the peer). MEASURED EXCEED (vs h2_serve_connection): an external curl given K same-origin URLs REUSES ONE h2 connection (total num_connects across the K transfers = 1) where the single-stream driver forces K separate connections. The persistent driver thus serves the SAME K requests on 1/K the TCP connections. WHY A NEW ORGAN (rule 9 single-responsibility + rule 25 build-don't-strip): h2_serve_connection is GATED GREEN and REUSED by the proven N=3 daemon; it is left BYTE-UNTOUCHED. Persistent multi-stream is a DISTINCT connection lifecycle (keep-alive read loop with frame compaction + per-stream response + single terminal GOAWAY) -- folding it into the single-stream driver would collapse "serve-one-then-close AND serve-many-keep-alive" into one organ (the 'and' split-test fails). So this organ is a SIBLING driver composing the same proven framing + tls transport stones. DRIVER CONTRACT: h2_serve_connection_multi(ss_fd, srand, sxpriv, cert_der, cert_len, ed_priv, body, blen, max_streams) -> i64 The session is established INSIDE via run_h2_ed25519 (handshake inputs are caller args; single-responsibility -- caller hands an already-ACCEPTED fd +