fix(parser): accept real Cognito trigger events from common flows

[vishwakt]

Summary

The Cognito trigger schemas rejected events Cognito sends in common flows, so custom auth flows and custom email senders could not be parsed at all. This aligns them with the events captured from a live user pool in the issue and with the trigger sources reference.

Changes

• PreSignupTriggerSchema and PostConfirmationTriggerSchema accept every documented triggerSource for their trigger (PreSignUp_AdminCreateUser, PreSignUp_ExternalProvider, PostConfirmation_ConfirmForgotPassword) instead of a single literal.
• CustomEmailSenderTriggerSchema and CustomSMSSenderTriggerSchema accept every documented source for their trigger, no longer require a response (real events have none, since Cognito expects nothing back), and accept a null clientMetadata.
• DefineAuthChallengeTriggerSchema and CreateAuthChallengeTriggerSchema accept an empty session, which the first call of a custom auth flow without SRP sends.
• VerifyAuthChallengeTriggerSchema accepts a null response.answerCorrect, which Cognito sends for the function to set.
• callerContext.clientId accepts null in the shared base schema, which admin API operations such as AdminConfirmSignUp send.
• Added the eight events captured in the issue as fixtures, with a round-trip test for each. All eight fail against the schemas on main. The two existing custom sender tests no longer pass a response, matching real events, and the custom sender JSDoc examples drop it too.

PreSignUp_ExternalProvider and the custom SMS sender sources come from the documentation, since they weren't captured. The trigger sources overview spells the SMS sources CustomSmsSender_*, while the custom SMS sender page and the API mapping table use CustomSMSSender_*, matching the existing literal, so I used the latter.

Issue number: closes #5770

---

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.

[svozza]

This is looking good, one change I'd like, which I should have mentioned in the issue. Rather than have lots of JSON files, let's have a single one that we use to derive the other events. You can see an example in #3388.