gh-128949: Preserve payload line endings in BytesParser.parse

[sankalpsthakur]

Fixes #128949. Thanks to tnakamot and medmunds for the reports.

Disable universal-newline translation in the binary parser's TextIOWrapper. CRLF and bare CR bytes in unencoded attachments must not become LF; parsing a binary file now agrees with parsebytes(). Header recognition and ownership of the caller's stream are unchanged.

The follow-up in 9634201 preserves mailbox.Message's existing universal-newline behavior for binary streams, without reverting the email parser fix. Bytes input still preserves line endings, and the caller's stream remains open.

Regression coverage includes both policies, text/binary payloads, 7bit/8bit/binary transfer encodings, multipart attachments, an 8192-byte read boundary, header-only parsing, and mailbox stream/bytes construction with LF, CRLF and CR.

Validation

Original before/after run, Linux debug build based on 2385254: the new email assertions fail twice before the change and pass afterward. The test_email, test_mailbox, test_imaplib, test_poplib and test_smtplib selection passes (2,629 tests run, 5 skipped); test_email -R 3:3 and git diff --check pass. This run predates the mailbox follow-up.

Upstream run 35378510395 for head 9634201 completed with all seven Windows jobs and the other runtime test jobs passing. CLA, lint and label checks also pass. The workflow remains failed because Docs rejects the new NEWS reference to email.parser.BytesHeaderParser.parse; the required-check aggregate consequently fails. The two-line NEWS correction is prepared but not pushed or Sphinx-tested.

AI tools assisted with implementation, validation and this description.

• Issue: email.parser.BytesParser.parse() cannot handle binary data that include \x0d \x0a correctly. #128949

[sankalpsthakur]

Found a mailbox compatibility regression while investigating the Windows failures on 5a0df99: with CRLF storage, Maildir/MH now return CRLF payloads while get_bytes() still normalizes to LF. test_add_8bit_body expects LF.

A candidate follow-up keeps universal-newline conversion in mailbox.Message's binary-stream constructor, without reverting the email parser fix. On Linux/Python 3.13.5, the new constructor tests have 12 failing subcases with the PR behavior and none with that follow-up; the separate compatibility probe passes 18/18. This uses the inspected constructor and simulated CRLF storage, not a CPython 3.16 or native Windows run. The Windows job logs returned 404, so I have not confirmed this accounts for every CI failure. The follow-up is not committed yet.

[sankalpsthakur]

The mailbox fix is in 9634201, and all seven Windows jobs now pass; the remaining failure is the NEWS reference to BytesHeaderParser.parse.
A two-line correction links to the documented class instead; patch-application checks pass, but it is not pushed or Sphinx-tested.