[Lambda] Memory Issue: Fail Faster

### 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**
When insufficient memory is allocated to an AWS Lambda function, the function executes until it times out, even though it cannot complete successfully. This results in unnecessary billed duration. A configurable option to fail fast or fail directly when memory is insufficient would be beneficial.

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

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
When a Lambda function lacks sufficient memory, it continues running until the timeout duration is reached. This leads to wasted execution time and higher costs, as users are billed for the full timeout duration. Detecting and stopping such executions earlier would save time and reduce costs.

However, this behavior may not be relevant in all cases. For example, some developers might intentionally use all available memory for caching purposes, or runtimes like Java JVM could utilize all memory without necessarily indicating a failure. For Python runtimes, however, insufficient memory often results in this timeout behavior. Providing an option to configure the default behavior—either fail fast or continue until timeout—would allow developers to tailor Lambda execution to their specific use case.

**Are you currently working around this issue?**
The current workaround involves setting shorter timeout durations or waiting for the execution to complete to identify memory-related issues. Both approaches are inefficient and do not address the root problem.

**Additional context**
This issue has been observed with Python runtimes (both managed and OCI-image-based) on ARM and x86 architectures.

**Attachments**
N/A