fix(negotiation): distinguish missing Accept-Encoding from empty or restrictive values #11

Behavior mismatch

ContentEncoding::isSupported returns true for any coding not explicitly rejected. Its docblock and two current test expectations encode this rule, but it disagrees with HTTP negotiation: an existing Accept-Encoding field only admits listed codings or a matching wildcard, and an explicitly empty field requests no content coding.

Evidence

Commit a429fbe9a7efce6cee50b82e4a981ea7e3b47a5f.

• Implementation and fallback.
• Tests currently expecting implicit acceptance.
• RFC 9110 §12.5.3: absent and present-empty are different; identity has its own default-acceptance exception.

Regression cases

With mb_trim/mb_strtolower available:

• isSupported(Deflate, 'gzip, br'): expected false, current true.
• isSupported(Gzip, '') when an explicitly empty header is passed: expected false, current true.
• isSupported(Identity, 'gzip, br'): remains true.
• An absent header should still allow any coding; the current required string parameter cannot distinguish absent from present-empty.

Impact: a caller can select compression that a client did not advertise/cannot decode.

Acceptance criteria

Document and represent absence separately (for example nullable input or caller-level presence check), apply listed/wildcard/identity rules, correct the existing test expectations and add absence vs empty cases. Preserve explicit q=0 exclusions and aliases.

Priority P2; high-confidence conceptual/standards mismatch, not a security claim. Source analysis only; no PHP runtime available. No duplicate among existing issues/PRs #1–#8 or new #9–#10; #9 covers function availability and #10 covers a separate media-type selection algorithm.