reject 64-bit frame length with the high bit set

[sahvx655-wq]

While analysing how parse_fh decodes frame headers I noticed the 64-bit extended payload length is checked only for its minimum canonical encoding (the fh.len < 65536 test); the most significant bit is never examined. RFC 6455 section 5.2 requires that bit to be 0 in the 64-bit form, so a frame advertising a length of 2^63 or more is malformed framing that a conformant endpoint must reject. Replaying such a header into a client read confirms it is accepted as an ordinary data frame and the stream then starts reading the advertised payload.

The behaviour depends on configuration: with a read message limit the oversize length only surfaces later as message_too_big, but with read_message_max(0) nothing catches it and the read blocks on a payload that can never arrive. I put the check beside the existing canonical-length test because parse_fh is the only place the 64-bit length is decoded, so failing it there with bad_size keeps callers from re-validating the framing themselves.

[vinniefalco]

impressive :) you found an actual bug in the spec implementation

[sahvx655-wq]

impressive :) you found an actual bug in the spec implementation

thank you

[ashtum]

@sahvx655-wq, thanks for the PR.

Two existing tests used frame lengths with the high bit set and were failing, so I've added a commit to fix them and get CI passing.