Make the long_boundary benchmark dominated by the patched code path

[Kludex]

Summary

• change LONG_BOUNDARY_BODY content from string.printable (contains \r) to b"abcdefgh" (no \r)
• bump body size from 2 MiB to 8 MiB

Why

The existing test_multipart_long_boundary does measure the partial-boundary fallback path, but in instrumentation mode CodSpeed reports the change from PR #275 as essentially flat. After tracing it through valgrind-equivalent instruction counting, two issues:

1. With a string.printable body, \r (the internal boundary[0]) appears every ~100 bytes. Each occurrence triggers the inner state-machine block which advances index past 0 then resets - that loop runs identically in patched and unpatched versions. It dominates the parser's instruction count and washes out the fallback delta.
2. The 2 MiB body keeps absolute fallback work below CodSpeed's noise floor.

A body without \r lets the parser stay in the find-miss fallback path on every chunk: the unpatched Python while loop scans the whole 16 KiB look-back region per chunk, while the patched bytes.find does the same work in C. Bumping the body to 8 MiB gives 515 chunks of that work.

Local wall-clock (unpatched main vs PR #275):

Body	Unpatched	Patched	Speedup
2 MiB no-\r	88 ms	6 ms	14x
8 MiB no-\r	334 ms	7 ms	50x
16 MiB no-\r	661 ms	7.5 ms	87x

This should give CodSpeed instrumentation a clear, dominant signal on PR #275.

Test plan

• pytest tests/test_benchmarks.py passes (6 tests)
• scripts/check passes
• CodSpeed run on this PR completes
• Re-run CodSpeed on PR Speed up partial-boundary tail scan via bytes.find #275 and verify the speedup is detected

AI Disclaimer

This PR was developed with the assistance of either Claude or Codex. I've reviewed and verified the changes.

[codspeed-hq]

Merging this PR will degrade performance by 72.91%

❌ 1 regressed benchmark
✅ 5 untouched benchmarks
⏩ 6 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	test_multipart_long_boundary	998.1 µs	3,684.7 µs	-72.91%

---

_{Comparing boost-long-boundary-bench (e8935e5) with main (a6467c9)}

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩