feat(parser): add errorHandler option for inline parse error handling

[Zelys-DFKH]

Summary

Changes

Adds an optional errorHandler callback to ParserOptions, letting callers intercept parse failures and return a custom response instead of throwing.

The motivation comes from #4191: when @parser is stacked with other decorators that expect a fully-typed event, safeParse: true doesn't compose well -- the outer decorators see ParsedResult rather than the actual payload. An error handler keeps the event type clean while still providing a recovery path on parse failure. Thanks to @codyfrisch for walking through this use case in detail.

The callback receives the ParseError. If it returns a non-undefined value, that becomes the Lambda/Middy response and stops further processing. If it returns undefined, the original error is rethrown -- so you can handle specific failure cases without silently absorbing unexpected ones. Non-ParseError exceptions (e.g., from schema transforms) always propagate as-is.

Both the @parser class decorator and parser() Middy middleware support the new option.

Issue number: closes #4191

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud