Fix: handle malformed multipart bodies

[mnapoli]

When a POST request has a multipart/form-data content type but a body that riverline/multipart-parser cannot parse, Psr7Bridge lets the parser's exception escape. The Lambda invocation fails before the application runs: the client gets a 5xx, the application cannot handle it, and the process restarts.

This happens with valid requests too: a FormData with no fields is sent by browsers as just the closing boundary (--boundary--), which the parser rejects with LogicException: Can't find multi-part content. We saw this in production with a Laravel Octane application.

PHP-FPM never fails on these bodies: PHP gives an empty $_POST (or what it could parse) and the application decides what to do. This only affects the PSR-7 bridge (Octane, PSR-15 and other handlers that use Psr7Bridge).

The bridge now catches the parser's exceptions (LogicException, which InvalidArgumentException extends) and ignores the body: no parsed body and no uploaded files, the raw body is still available. A failure to create a temporary file is still reported.

I considered returning a 400 instead, but:

• an empty form is a valid request, it must not be rejected
• the response would be generated by Bref outside of the application (no middleware, no CORS headers, not reported by the application's error handler)
• it would make the PSR-7 bridge behave differently from PHP-FPM

The new test covers an empty form, an empty body, a missing closing boundary, a content type without boundary and a nested multipart/mixed part. All 5 cases threw before this change.