reject content-length with transfer-encoding regardless of order

[sahvx655-wq]

do_field already treats Content-Length and Transfer-Encoding as mutually exclusive, but only catches the conflict for some header orderings. I was going back over the conflict handling after the recent framing work and the two branches are not symmetric: the Transfer-Encoding branch bails out when flagContentLength is set, and the Content-Length branch bails out when flagChunked is set, yet a Transfer-Encoding whose coding does not resolve to chunked (say Transfer-Encoding: gzip) records no flag at all. So Transfer-Encoding: gzip followed by Content-Length: 5 is accepted and framed by the Content-Length, while the very same two fields in the opposite order are rejected with bad_transfer_encoding.

Header field order deciding whether a request is rejected is the Content-Length / Transfer-Encoding desync that RFC 7230 3.3.3 forbids: a front-end that honours the Transfer-Encoding and Beast honouring the Content-Length disagree about where the body ends, which is a request smuggling primitive. I record the presence of any Transfer-Encoding in a new flag and reject a following Content-Length, so the conflict is caught at whichever field completes it no matter the order or the coding. The check stays in do_field next to the existing conflict logic so finish_header still sees a consistent flag set. The regression test exercises both orderings.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.26%. Comparing base (736daa0) to head (630b87a).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3098      +/-   ##
===========================================
- Coverage    93.28%   93.26%   -0.03%     
===========================================
  Files          177      177              
  Lines        13750    13751       +1     
===========================================
- Hits         12827    12825       -2     
- Misses         923      926       +3     

Files with missing lines	Coverage Δ
include/boost/beast/http/basic_parser.hpp	94.11% <ø> (ø)
include/boost/beast/http/impl/basic_parser.ipp	97.45% <100.00%> (+0.23%)	⬆️

... and 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 736daa0...630b87a. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.