Apply the effect of a SETTINGS_INITIAL_WINDOW_SIZE change to a window. Per RFC 7540 §6.9.2: every active stream's window is adjusted by the signed difference between the old and new settings. If the resulting window would exceed the maximum, FLOW_CONTROL_ERROR.

Hard cap on the cumulative *compressed* bytes of one header block (HEADERS + any CONTINUATION frames). HPACK can be denser than the uncompressed form (the whole point of indexed representations) so this is set to the decoded cap; combined with the per-block decoded check it leaves no path for an unbounded attacker accumulation.

Default cap (in bytes, RFC 7541 §4.1 accounting) on the decoded size of a single header list. Chosen to match Suave's HTTP/1.1 header-buffer heuristics and the de-facto industry default (Tomcat / IIS ~32 KiB).

Encode a list of (name, value) headers as a single HPACK header block using the per-connection encoder dynamic table. Uses `defaultEncodeStrategy` (Linear algorithm, no Huffman) which yields output that any compliant HPACK decoder — including the in-tree `Hpack.decodeHeader` — can parse.

Estimate a safe upper bound for the encoded byte length of `headers`. HPACK's worst case for a Linear-without-Huffman encoding of a single (name,value) pair is `1` (type byte) + `5` (length prefix for name) + `name` + `5` (length prefix for value) + `value` bytes; we round up to `name + value + 32` per header (matching `headerSizeMagicNumber`) and double that to leave headroom for any table-size-update prefix the encoder may emit on the first call.

Translate a list of decoded HPACK headers into the shape expected by `HttpRequest`: split the pseudo-headers (`:method`, `:path`, `:scheme`, `:authority`) out of the regular header list per RFC 7540 §8.1.2.3 and validate that the mandatory request pseudo-headers are present. Returns `Ok (method, path, scheme, authority, regularHeaders)` on success, or `Result.Error ProtocolError` on a missing or repeated pseudo-header.

Feed a CONTINUATION frame (or any other frame, to detect interleaving).

Get 31-bit int from 4-byte array (which MUST be in network order)

Apply a WINDOW_UPDATE delta to a window. Per RFC 7540 §6.9.1: - a delta of 0 is a stream-level PROTOCOL_ERROR - causing the window to exceed 2^31 − 1 is FLOW_CONTROL_ERROR - a negative delta is illegal (WINDOW_UPDATE.windowSizeIncrement is unsigned 31-bit)

Maximum legal flow-control window size per RFC 7540 §6.9.1.

Poke a 16-bit int into a byte array in network byte order (big-endian)

Poke a 32-bit int into a byte array in network byte order (big-endian)

Read exactly `n` bytes from the connection's pipe reader into a fresh array. Replaces the legacy `ConnectionFacade.readBytesToArray` helper that no longer exists on the current facade. Used by the HTTP/2 frame reader. Returns an `Error` if fewer than `n` bytes are available before the pipe stops yielding data (e.g. peer closed the connection mid-frame), since short reads on HTTP/2 frames are protocol errors per RFC 7540 §5.4.1.

Read a frame header and its raw payload, without decoding the payload. Used by the connection's read loop so that frame-level validation (RFC 7540 §4.1/§4.2/§6.x) can run before the per-type parser, which otherwise asserts on malformed inputs.

Begin reassembly with a HEADERS or PUSH_PROMISE frame.

Apply a state event. Returns the new state on success, or an error code on protocol violation (per RFC 7540 §5.1 the listed responses are PROTOCOL_ERROR or STREAM_CLOSED). RST_STREAM and END_STREAM transitions to Closed are always permitted.

Attempt to consume `n` octets from the window. Returns `true` on success (the window was decremented) or `false` if the window is too small. Callers that get `false` must block / queue the data until WINDOW_UPDATE arrives. A negative `n` is treated as a caller bug and returns `false` without mutating the window. Frame-level validation (parseFrameHeader, etc.) should already have rejected anything that could produce a negative length; this is defence in depth.

Per-type validation that depends only on the header and the raw payload length. RST_STREAM additionally needs to know whether the stream is in the Idle state (i.e. never opened), which the caller provides through `isIdleStream`.

Validate the individual entries of a SETTINGS payload against the per-identifier rules in RFC 7540 §6.5.2. The decoded `parseSettings` helper discards out-of-range values silently (e.g. coerces SETTINGS_ENABLE_PUSH = 2 to `false`), so this validator works against the raw payload bytes before parsing.