* SECURITY UPDATE: server.maxHeadersCount / request.maxHeadersCount are published to the HTTP parser as parser.maxHeaderPairs, but the limit was only applied when the JavaScript layer assembled the headers object: the parser itself kept accepting and buffering header field/value pairs without bound, so a peer could make the process hold far more header data than the configured count allows (CVE-2026-58044) - debian/patches/CVE-2026-58044.patch: add Parser::TrackHeaderPair() to src/node_http_parser_impl.h and call it from on_header_field() at the start of every new field name, so the pair counter is compared against parser.maxHeaderPairs in C++ and the message is aborted with a header-overflow error as soon as the limit is exceeded; the counter is reset in Init(), on_headers_complete() and on_message_complete(). The one llhttp-only call, llhttp_set_error_reason(), is guarded with #ifdef NODE_EXPERIMENTAL_HTTP so the traditional (legacy http_parser) compilation of the same header still builds and still enforces the limit. Also adds the upstream regression test test/parallel/test-http-max-headers-count-overflow.js and the upstream rewrites of test/parallel/test-http-max-headers-count.js and test/parallel/test-https-max-headers-count.js - CVE-2026-58044