HTTP/2 client HPACK desynchronization via header blocks for unknown streams in HTTP.jl

Summary

### Description

The HTTP/2 client's `_process_incoming_frame!` dropped HEADERS/CONTINUATION frames for stream ids absent from `conn.streams` without passing the header block through the connection's HPACK decoder. Because HPACK's dynamic table is connection-scoped and mutated as a side effect of decoding each header block (RFC 7541 §2.3.2/§4), skipping even one block permanently desynchronizes the client decoder from the server encoder, causing later indexed header references on other multiplexed streams to resolve to wrong name/value pairs or throw "HPACK index out of range". This is reachable by a malicious server or by a benign race where trailers arrive after a stream is unregistered. The client also lacked the CONTINUATION sequencing enforcement the server already performed.

### Impact

A malicious server (or a race condition) could corrupt HPACK header decoding across all multiplexed streams on a client connection, producing incorrect header values or connection errors.

### Patches

Fixed in HTTP.jl v2.4.0. Header blocks for unknown/closed streams are now accumulated (bounded by `max_header_block_bytes`) across HEADERS+CONTINUATION and HPACK-decoded purely for the dynamic-table side effect before being discarded, and a CONTINUATION sequencing guard (RFC 7540 §6.10) is enforced on the client read loop.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.