feat(detection): cap request-body inspection by Content-Length (S4)

[rennf93]

Summary

Design-partner feedback S4 — on a high-traffic auth proxy that sometimes receives request bodies up to ~300MB, penetration/body inspection had no size guard at the read point, so a large body was fully buffered + decoded into memory before scanning. This bounds that read.

Change

• New SecurityConfig.detection_max_body_inspect_bytes (default 262144 / 256 KiB; ge=1024, le=10485760).
• detect_penetration_attempt now skips reading + scanning the body when the Content-Length header exceeds the cap (returns a clean detection-miss), avoiding the buffer/decode entirely on the hot path.
• The existing detection_max_content_length only truncates inside the regex preprocessor — after the full body is already in memory — so it doesn't help here; this bounds the read itself.

The cap decision is a small pure helper (_body_exceeds_inspection_cap) so the hot-path function stays within the project's complexity budget.

Scope / safety

Config-only direct read (matches detection_max_content_length; no route override). Async + unasync sync mirror. Backward compatible — the default (256 KiB) is well above normal bodies.

Verification

• check-sync: OK · ruff + ruff-format + mypy + vulture + xenon + deptry: clean · bandit: exit 0
• 8 new tests (over / at / missing / malformed Content-Length × async + sync)
• Full suite: 3704 passed, 100% line + branch coverage (0 missed), zero warnings

Part of the coordinated guard-core 3.2.0 release.