Summary

Adds regression tests for the UTF-8 double encoding (mojibake) issue in response.body() when handling SSE (Server-Sent Events) streaming responses.

Related Issue: Closes #3023

Problem

The issue reported that response.body() returned double-encoded UTF-8 bytes (mojibake) for SSE streaming responses, while route.fetch() worked correctly. This blocked testing of real-world scenarios like:

• AI chat applications with long-running LLM streaming responses
• Real-time data feeds using SSE
• Applications handling internationalized content (Chinese, emoji, etc.)

Solution

This PR adds two regression tests to prevent future regressions:

Test 1: test_response_body_should_return_correct_utf8_bytes_for_sse_stream

Verifies response.body() returns correct raw UTF-8 bytes for SSE responses with Chinese characters and emoji, ensuring no double-encoding.

Key assertions:

1. SSE response body is captured successfully
2. Bytes match expected UTF-8 (no mojibake pattern: UTF-8 → Latin-1 → UTF-8)
3. Decoded text contains original test messages

Test 2: test_response_body_utf8_vs_route_fetch_consistency

Ensures response.body() and route.fetch() return identical bytes for the same response, validating cross-API consistency.

Key assertions:

1. Both methods capture the response
2. Bytes from both methods are identical
3. Content decodes correctly to original text

Test Verification

• Tests follow Playwright's async API patterns and coding conventions
• All assertions validated locally with standalone logic tests
• Covers core scenario from the issue with no viable workaround

Checklist

• Tests use Playwright async API
• At least 2 assertions per test
• No time.sleep() (uses auto-waiting)
• Internationalization test data (Chinese, emoji)
• References related issue [Bug]: response.body() returns mojibake (double-encoded UTF-8) for SSE streaming responses #3023