HttpPostMultipartRequestDecoder corrupts data with a trailing CR when a chunk boundary splits the CRLF before the delimiter

Expected behavior

Decoding a multipart body must produce the same attribute values and file upload contents regardless of how the body is split into HTTP chunks.

Actual behavior

When a multipart part has no declared per-part Content-Length and an HTTP chunk ends exactly with the CR of the CRLF that precedes the next boundary delimiter, HttpPostMultipartRequestDecoder appends that CR to the part content. The delimiter still matches on the next chunk (starting with \n--boundary), so decoding "succeeds" with silently corrupted data: an attribute value bar becomes bar\r, a file upload body hello world becomes hello world\r.

The #11668 fix in loadDataMultipartOptimized holds back a trailing CR, but only under the condition httpData.definedLength() == httpData.length() + readableBytes - 1. Parts without a declared length have definedLength() == 0, so the hold-back never applies to them.

Steps to reproduce

Feed a multipart body to the decoder in two chunks, cutting between the CR and LF of the CRLF that precedes the closing delimiter. A split-fuzz probe that decodes the same body whole vs. split at every byte offset shows mismatches at exactly those offsets (for both attributes and file uploads).

I will submit a PR with a failing test and fix.

Netty version

4.2 branch (a54bbf9), also affects 4.1.

JVM version / OS

OpenJDK 21, macOS (not platform-specific)