HPACK Huffman decoder drops embedded NUL bytes from header values

The HPACK Huffman decoder silently discards `0x00` octets from decoded header field names and values. RFC 7541 Appendix B assigns the NUL octet (symbol 0) the 13-bit Huffman code `0x1ff8`, so it is a valid symbol that must survive an encode/decode round-trip; here it vanishes and the value's length shrinks, with no error, so two peers using this codec disagree on the header contents.

```ocaml
let () =
let value = "aaaaa\000aaaaa" in (* length 11, with an embedded NUL *)
let enc = Hpack.Encoder.create 4096 in
let f = Faraday.create 256 in
Hpack.Encoder.encode_header enc f { Hpack.name = "x-test"; value; sensitive = false };
let wire = Faraday.serialize_to_string f in
let dec = Hpack.Decoder.create 4096 in
match Angstrom.parse_string ~consume:All (Hpack.Decoder.decode_headers dec) wire with
| Ok (Ok (h :: _)) -> Printf.printf "%S\n" h.Hpack.value
| _ -> Printf.printf "decode failed\n"
```

This prints `"aaaaaaaaaa"` (length 10) rather than the original 11-byte value. The cause is the decoder's `0x00` handling: the Huffman table uses `0x00` as a "no symbol here" marker, conflated with a real decoded NUL, so simply removing the `if c <> '\000'` guard would emit spurious bytes; the marker and a real NUL need distinguishing.