[MDA2AV]

Fixes #65

Why

The ReadOnlySequence entry points found the CRLFCRLF, then copied the whole sequence with ToArray() — any pipelined body included — and only then parsed, which is where MaxTotalHeaderBytes was checked. A tiny header followed by a large pipelined body forced an allocation the size of the body, per parse:

• UltraHardenedParser.TryExtractFullHeaderValidated (requests)
• UltraHardenedParser.TryExtractFullResponseHeaderValidated (responses)
• FlexibleParser.TryExtractFullHeader

What changes

The SequenceReader that located the terminator already knows the header block's length: reader.Consumed, CRLFCRLF included. So:

• the two hardened entry points reject a block over MaxTotalHeaderBytes with the same 431 ("Total header size exceeds limit.") before copying anything;
• all three copy input.Slice(0, reader.Consumed) instead of the whole sequence.

The ROM parse never reads past the terminator, so parsed fields and bytesReadCount are unchanged; only the size of the copy changes. The XML summaries that said "linearized via ToArray()" now say what is copied.

Out of scope, possible follow-up: a header section that never terminates is still buffered by the caller and rescanned on each call (single- and multi-segment alike). Rejecting an unterminated buffer that has already reached MaxTotalHeaderBytes would bound that too, but it changes the incomplete path of both entry points, so it is not folded in here.

Overlap with sibling PRs

• LF-only messages read as incomplete forever; bare-LF strictness is unreachable #59 rewrites the completeness check two lines above (TryReadPastHeaderEnd) and advances the same reader past a bare-LF block's \n\n, so this copy covers bare-LF blocks too. A trial merge of the two branches is conflict-free and passes all 493 tests.
• bytesReadCount is one less than the bytes consumed, and the doc says otherwise #58 renames the parse call on the line right after the copy, so merging the two conflicts in all three files. Resolve by keeping this PR's copy lines with bytesReadCount is one less than the bytes consumed, and the doc says otherwise #58's method names. Verified: with every open PR merged together, the solution builds and 1114 tests pass.

Tests

New tests/Tests/MultiSegment.HeaderCopy.cs (10 cases), for requests, responses and FlexibleParser:

• an 8 MiB pipelined body behind a multi-segment header: the parse is correct, the array backing the parsed slices (MemoryMarshal.TryGetArray) is exactly the header length, and the thread allocates < 64 KiB for the call;
• the terminator split at each position across two segments, and a body that starts in the terminator's own segment: the copy is still exactly the header block;
• a header one byte over MaxTotalHeaderBytes: 431, with < 1 MiB allocated for the call (so not the 8 MiB body); exactly at the limit: parses.

9 of the 10 fail against main (the exact-limit case passes on both). 413 passing, 0 failing (net10.0); the solution builds for net8.0/net9.0/net10.0.