BUG/MEDIUM: hpack: encode long methods and schemes using the long form

BUG/MEDIUM: hpack: encode long methods and schemes using the long form

hpack_encode_scheme() and hpack_encode_method() document that they're
limited to 127 chars since they only rely on hpack_encode_short_idx()
for literals, but the H2 mux doesn't check this. This results in only
the bytes modulo 256 being advertised on a backend connection. As such
the remaining bytes will be confused with other HPACK opcodes. Note
that in practice, the ability to exploit this to inject headers from a
front H1 connection is very limited due to the strict alphabet enabled
in schemes and methods which limits usable codes to literal headers with
indexing for absent pseudo-headers (i.e. no :scheme, :method, :path,
possibly one :authority when none is provided, but it must then match
the host), and whose value will be of 43 chars minimum.

The real impact in practice is to provoke protocol errors and cause
shared H2 backend connections to be abruptly closed in environments
using http-reuse always.

Let's simply make both encoders fall back to hpack_encode_long_idx()
for value larger than 127 bytes, like hpack_encode_path() does. The
bug has been present since 1.9 with commit 39c80ebff ("MINOR: hpack:
provide a function to encode an HTTP method").

Reported-by: Claude (ANT-2026-9SVV6W3Q)
This fix must be backported to all stable versions.