Set up backflow for Refunds

In order to notify users of a refund, emails need to be sent out as part of the process. This requires some updates to the pay listener in STRR so that it can also look for the queue message of reversed and act accordingly.

#### Background
After a long list of refunds issued, there are now users who will need to be notified - this effort saves from staff having to manually draft and send an email to each one.

#### Suggested steps (provided by Pay Team)
- [ ] Update the pay listener to also look for queue message of REVERSED
- [ ] Take the email address of the user submitting the application
- [ ] Email the user using GCNotify

Considerations:
- add in refund and pay amount in emails in case it's partial
- add in reversal reason in emails
- How does this affect the application state? is this refused? withdrawn? what about partial?
- Are there any situations where registrations are already created?
- Retroactive or only going forward?

### [Figma File](https://www.figma.com/design/a4H3s0ebAxwv8ZniyNAt4g/STRR-Host-Registration---Redesign?node-id=1896-104300)

Start by locating the STRR pay listener and its handling of queue messages, then trace how a REVERSED message would identify the submitting user's email. Review the refund amount, reversal reason, partial-refund state, and registration-state considerations before implementing GCNotify delivery. Done means eligible refund users receive accurate notifications without incorrectly changing application state.

Written by the indexing model from the issue text.