FIX: Calculate accurate UTF-8 byte length for content-length in HTTPTarget

[Vardhman Gupta (Kaap10)]

Description

While testing HTTPTarget with non-ASCII and multilingual prompts (such as Chinese characters and emojis), I noticed that requests were getting truncated on the receiving server.

Looking into HTTPTarget._send_prompt_to_target_async, the content-length header was being calculated using len(http_body). In Python, len() on a string returns the character count instead of the actual encoded byte count. Per RFC 9110, Content-Length must be the number of octets/bytes. For multi-byte characters (e.g. "你好" which is 2 characters but 6 UTF-8 bytes), sending content-length: 2 caused the payload to be cut short.

Summary of Changes:

• Updated _send_prompt_to_target_async to use len(http_body.encode("utf-8")) for string bodies so the byte count is accurate.
• Added handling for bytes/bytearray bodies.
• Avoided adding content-length when http_body is empty (e.g., bodyless GET requests).
• Used lowercase "content-length" to keep dictionary keys consistent with parse_raw_http_request.

Tests and Documentation

• Added test_send_prompt_async_content_length_utf8_bytes to verify multi-byte characters calculate the correct byte length.
• Added test_send_prompt_async_content_length_recalculated to check header updates when overriding raw requests.
• Added test_send_prompt_async_content_length_raw_bytes for raw byte payload testing.
• Updated existing test_http_target.py mock assertions.
• Verified with pytest tests/unit/prompt_target/ (all passed) and ruff check.

[Vardhman Gupta (Kaap10)]

This is ready for review. Thanks!