[pigri]

Follow-up to #35, which merged before these review findings were addressed.

The documented failure mode was wrong

#35 said h2 "allows a multiple of this value before failing the stream
outright". Measured on this branch, with a bound of 8KiB:

header list	result	pooled connection
2x (inside the 4x abuse multiplier)	stream error	alive
32x	connection error, header_list_way_too_large	dead

Past the multiplier it is a connection error, not a stream one. On a
pooled, multiplexed upstream that also fails every other request in flight on
that connection — where before the setting existed the response was simply
accepted.

That blast radius is the actual trade this setting makes: a bounded failure
on a shared connection instead of an unbounded header list. It is now in the
doc comment, and there is a test for the stream-local band that the old
comment described and nothing covered — both earlier tests drove 32x, so only
the connection-error path was ever exercised.

Reuse hash

h2_max_header_list_size now takes part in reuse_hash. #35 excluded it "like
the window sizes"; that was the wrong comparison. Those are tuning
parameters, this is a limit, and sharing a pool across different values
breaks it in both directions:

• a peer that set a bound gets none, if the pooled connection was established
  by a peer that set nothing;
• a peer that set nothing inherits a sibling's cap, and its legitimate large
  responses fail — taking the shared connection with them, per the table
  above.

A limit that applies or not depending on which peer connected first is not a
limit. New test: peers differing only in this value do not share a
connection, and identical peers still pool.

Some(0)

Rejected at handshake, as the two adjacent window settings already are. It
does not mean "no bound" — it makes the abuse limit zero too, so the first
response on every connection to that peer is a connection error, with no
diagnostic pointing at the config.

Test hardening

serve_one_fat_response swallowed its send failure. If a future h2 enforced
the peer's advertised SETTINGS_MAX_HEADER_LIST_SIZE on send, the server
would quietly send nothing and the oversize test would still pass on the
resulting error — going vacuous without failing. It now expects the send.

Not addressed here

The knob still has no consumer, so the exposure #35 described is not closed
by either PR. That is the synapse side and is next.

Verification

cargo fmt --check clean; cargo clippy --all-targets --all --deny=warnings
exit 0; cargo test -p pingora-core --lib 623 pass, with only
connectors::l4::tests::test_conn_error_addr_not_avail failing, which needs
host networking. Each new guard was mutated: removing the reuse-hash entry,
removing the zero check, and widening the band test each fail exactly one
test.

[linear-code]

SYN-317