[Lambda] Function URLs: Binary response data support

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

Enable Lambda Function URLs to return binary data (e.g., PDFs, images, Excel files) directly in HTTP responses.

**Which service(s) is this request for?**

AWS Lambda - Lambda Function URLs

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Building serverless web applications using Lambda Function URLs that need to serve binary content like PDF reports, Excel exports, and images. Lambda Function URLs cannot return binary data in responses - only text-based content is supported.

This forces unnecessary architectural complexity:
- Additional S3 bucket for temporary file storage
- Pre-signed URL generation and management
- Extra latency (write to S3 → generate URL → redirect client)
- Cleanup logic for temporary files
- Added costs for S3 PUT operations

API Gateway supports binary media types via `binaryMediaTypes` configuration, so this is technically feasible. Function URLs were positioned as a simpler alternative to API Gateway, but this limitation significantly reduces their utility.

**Are you currently working around this issue?**

Yes. We write binary content to an S3 "delivery bucket" and return a pre-signed URL with short expiration. The client follows this URL to download the file. This adds ~200-500ms latency, extra infrastructure, and operational overhead.

**Additional context**

- Base64 encoding works for small images but is impractical for larger files
- The existing 6MB payload limit would still apply - this is about content type, not size
- Common use case: serverless apps generating reports, exports, invoices