[Discussion] What's a proper integrity test for `zendesk__sla_policies`?

### Is there an existing feature request for this?

- [X] I have searched the existing issues

### Describe the Feature

## Context
Currently, when we run the `sla_count_match` integrity data validation test using our internal dataset, we get a handful of failures, specifically that the `zendesk__sla_policies` end model is missing some SLA records present in the source `ticket_field_history` table.

**Case 1**

Each of these missing records was a `requester_wait_time` SLA in which the SLA was either:
1. Applied to a ticket after the ticket was closed/solved, or
2. Applied to the ticket but there were no impacted status (`where ticket_historical_status.status in ('new', 'open', 'on-hold', 'hold'`)) after the SLA was applied.

In both cases, the package filters out this sort of SLA record because it was never actually active. It's not even like the `sla_elapsed_time = 0`, it's really just all null.

**Case 2**

For tickets which have multiple requester wait times and agent work times, we currently don't bring them all in as we only focus on one of the latest slas. Thus the `ticket_field_history` source will have a row count that differs between source and end models.

## Call to Action
So let this serve as a discussion thread --

For Case 1, would folks want these null records to persist to the `zendesk__sla_policies` end model? Are they helpful at all, or should we continue excluding them?

For Case 2, should we be applying requester_wait_time

### How would you implement this feature?

TBD

### Describe alternatives you've considered

_No response_

### Are you interested in contributing this feature?

- [X] Yes.
- [ ] Yes, but I will need assistance.
- [ ] No.

### Anything else?

_No response_

Start by reviewing the `sla_count_match` integrity validation and comparing `zendesk__sla_policies` with the `ticket_field_history` source, including `ticket_historical_status`. Reproduce the reported failures with the internal dataset if available, then resolve the open questions for null inactive SLAs and multiple requester or agent SLAs; completion requires an agreed behavior and corresponding test scope.

Written by the indexing model from the issue text.