Fix: Return empty content for multipart requests to match PHP-FPM behavior

[s2x]

Summary

For multipart/form-data requests, getContent() now returns empty string to match PHP-FPM behavior where php://input is not available.

Changes

• Modified RequestConverter::toSymfonyRequest() to pass empty content for multipart requests
• Improved content-type detection using stripos() instead of preg_match()
• Added 3 new tests for content behavior across different content types

Benefits

• Prevents duplicate memory usage (file data was stored twice in memory)
• Prevents data exposure via logging getContent()
• Consistent behavior with PHP-FPM

Testing

• All 25 RequestConverter tests pass
• Tests cover multipart, JSON, and form-urlencoded content types

Closes #68

[s2x]

[Suggestion] stripos() matches the substring anywhere in the string, whereas the original preg_match used ^ (start anchor) and \b (word boundary). In practice false positives are extremely unlikely, but this is a behavioral regression from stricter to looser matching.

Consider using str_starts_with() to preserve the original anchored behavior:

Suggested change

	$isFormUrlEncoded = stripos((string) $contentType, 'application/x-www-form-urlencoded') !== false;
	$ct = strtolower((string) $rawRequest->header('content-type', ''));
	$isFormUrlEncoded = str_starts_with($ct, 'application/x-www-form-urlencoded');
	$isMultipart = str_starts_with($ct, 'multipart/form-data');

— coder-model via Qwen Code /review

[s2x]

[Suggestion] Before this change, getContent() on a multipart request returned the full raw body. Now it returns ''. Any application code, middleware, or custom parser reading raw multipart data will silently break.

The behavior is correct for PHP-FPM compatibility, but this should be documented as a breaking change in CHANGELOG.md with a migration note so existing users are aware.

— coder-model via Qwen Code /review