Can check-enforcer handle pull_request_target, as well as pull_request?

Running into this while wiring up a required check in azure-dev: [ext-registry-check.yml](https://github.com/Azure/azure-dev/blob/main/.github/workflows/ext-registry-check.yml) (context on why it's `pull_request_target`: [Azure/azure-dev#9155](https://github.com/Azure/azure-dev/pull/9155)) — it has to run as `pull_request_target` because the whole point of the check is deciding whether the PR gets to skip core review, so the judging code can't come from the PR itself.

Tried wiring it into check-enforcer via the `workflow_run` fallback but copilot immediately flagged my change (in my workflow) because, apparently, that specific type gets skipped:

https://github.com/Azure/azure-sdk-actions/blob/1dc8fee9eaf3a8af294f4b299b0ebb3c6745bd2e/main.go#L259

```go
if workflowRun.Event != "pull_request" {
fmt.Println(fmt.Sprintf("Check enforcer only handles workflow_run events for pull requests. Skipping event for '%s'", workflowRun.Event))
return nil
}
```

Since my workflow's `workflow_run.event` is always `"pull_request_target"`, this branch would bail out (I think, every time).

Is this intentional, or something we could just patch up?

In the interim I was just going to add my stuff to branch protection, which comes with a slight penalty since my workflow now has to run everywhere, even if it just quickly no-ops, but it'll work for our purposes.

(BTW: the spot I'm doing this at is in this PR: https://github.com/Azure/azure-dev/pull/9155)

Start in main.go around line 259, where check-enforcer filters workflow_run events, and compare that handling with the pull_request_target workflow described in ext-registry-check.yml. Verify the workflow_run event value and trace whether it is skipped; done means the pull_request_target case is handled appropriately instead of being rejected by the current pull_request-only check.

Written by the indexing model from the issue text.