fix: limit outgoing HTTP body reads before trimming

[DevSars24]

Fixes #114

What was happening

DebugProbeHttpClientHandler was calling ReadAsStringAsync() on every outgoing request and response body — meaning the entire body was loaded into memory first, and only then trimmed down to MaxBodyCaptureSizeBytes.

For large payloads this creates unnecessary memory pressure proportional to the actual body size rather than the configured capture limit.

What I changed

Rewrote CaptureBodyAsync to read directly from the stream using a byte buffer, stopping as soon as MaxBodyCaptureSizeBytes is reached. No more full-body allocation.

Key decisions:

• Used LoadIntoBufferAsync() before reading the stream so the original HttpContent is fully preserved and the actual outgoing HTTP request is never affected
• Allocated limit + 1 bytes in the buffer — if totalRead exceeds the limit, we know the body was truncated without needing a second read
• Truncated bodies get [truncated] appended after decoding so consumers can tell the capture is incomplete
• UTF-8 used explicitly for decoding
• All existing null and non-text-content guards left completely unchanged

Test Results

• 5 new tests added — all passing
• 51 existing tests passing
• 3 pre-existing failures unrelated to this change (net10 PipeWriter compatibility issue)