Check most recent status prior to sending ZSF email

[baltes]

Before sending a given ZSF email, check the record against the PEGA reporting API to verify that it is still a missing status, so that we can confirm that the status hasn't been updated between initial missing status notification and sending the silent failure email.

[andrea-merrill]

blocking until the two stories it is dependent on are at least in progress or done

[baltes]

Moving this out of the blocked column so that's it's prioritized appropriately in the backlog. Technically blocked, but this is an optional follow on with dependencies on other work. Not an immediate priority.

[baltes]

Dependency on #94284

[andrea-merrill]

Adding this in case it's helpful: FMP: Process to monitor missing statuses and send ZSF emails

This is the original ticket that has the monitor that kicks off the ZSF emails to to users. Not sure if we intend to make changes to the monitor for this ticket or not.

[michaelclement]

UPDATE: Cindy says we can request that she add form_uuid as a property to the PEGA report and she can put it in the backlog. @baltes would formally request that change it sounds like.

Slight issue with this:
When a record on our side has a missing pega status (pega_status: nil), that means that record also won't have a case_id property (as that's provided when the PEGA API hits our callback with the status upon ingestion.

Since that's the case, we don't have any way of querying the PEGA reporting endpoint for our specific record because the only data point they could possibly share is case_id (which we by definition won't have in this circumstance).

I asked Cindy on Teams about including the form_uuid key in the PEGA reports but she said they can't do that.

@baltes We'll need to talk more about what we want to do here to move forward
CC @andrea-merrill

[michaelclement]

Work done so far in this PR