Batch OData request tests fail on linux

Assemblies affected
Which assemblies and versions are known to be affected e.g. ASP.NET Core OData 8.x

origin/main at 85944be02964c2643d1505b7777e3f535280f959
ASP.NET Core OData 9.4+

Describe the bug

Pulling the newest version from main, then running the tests causes (among others) Batch request processing tests to fail.
For example DefaultODataBatchHandlerTest.ProcessBatchAsync_DoesNotCopyContentHeadersToGetAndDelete() test.
This test fails on Assert.Contains("POST,3,text/plain; charset=utf-8", responseBody); as the request body is parsed as "bar\n--40e2c6b6-e6ce-43aa-9985-ddc12dc4bb9b--\n".
The multi-part boundary for some reason is included in the request body for that batch causing it's ContentLength to be 45 instead of 3.

Checking other batch tests it seems that they correctly leave out the boundary, and as such this is incorrect.

Reproduce steps

Pull origin/main at earlier mentioned commit and run the tests

Data Model

This is using the unit-test preset datamodel

Request/Response

An example from the failing test:
Request:

--40e2c6b6-e6ce-43aa-9985-ddc12dc4bb9b
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 483818399

GET / HTTP/1.1
Host: example.com


--40e2c6b6-e6ce-43aa-9985-ddc12dc4bb9b
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1035669256

DELETE / HTTP/1.1
Host: example.com


--40e2c6b6-e6ce-43aa-9985-ddc12dc4bb9b
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 632310651

POST /values HTTP/1.1
Host: example.com
Content-Type: text/plain; charset=utf-8

bar
--40e2c6b6-e6ce-43aa-9985-ddc12dc4bb9b--

Response:

Content-Type: application/http
Content-Transfer-Encoding: binary

HTTP/1.1 200 OK

GET,,
--batchresponse_362e965a-c20d-4348-91a1-2615d3af271a
Content-Type: application/http
Content-Transfer-Encoding: binary

HTTP/1.1 200 OK

DELETE,,
--batchresponse_362e965a-c20d-4348-91a1-2615d3af271a
Content-Type: application/http
Content-Transfer-Encoding: binary

HTTP/1.1 200 OK

POST,45,text/plain; charset=utf-8
--batchresponse_362e965a-c20d-4348-91a1-2615d3af271a--

Expected behavior

The tests expects the response for the last POST to return contentlength of 3, for the body "bar", yet the boundary tag is included and this test fails.

Screenshots

The location where the body is parsed over to the batched request:

As seen the buffer is containing the boundary tag, along with the body.

Additional context
Running the tests on Linux 6.18.8-1-manjaro
dotnet version 10.0.100

When looking at the other tests it seem they're expecting windows-terminated lines in the request, yet the requests made only contain the linefeed character.
Looking at the Http spec CRLF is only required in the header fields and not explicitly required in the body, although it does recommend parsing to ignore the return character.
This is going quite deep into the internals of request parsing streams so I'm unsure which part of the library is handling this incorrectly, or if the tests need to be updated to handle CRLF correctly. I am however happy to make a pull-request for these fixes if I'm able to.

Start by running DefaultODataBatchHandlerTest.ProcessBatchAsync_DoesNotCopyContentHeadersToGetAndDelete() on Linux at origin/main commit 85944be02964c2643d1505b7777e3f535280f959. Compare the batch request parsing with the other batch tests, paying attention to line endings and boundary handling. Done means the POST response reports content length 3 for "bar", the boundary is excluded, and the relevant batch tests pass.