HRA ignores webhook repository scale up events (but acks scaleDown)

Describe the bug
It appears that under certain conditions, HRAs configured against a RunnerDeployment repository is not recognized on scaleUp events (but is recognized for scaleDown events)

Checks

• My actions-runner-controller version (v0.x.y) does support the feature
• I'm using an unreleased version of the controller I built from HEAD of the default branch

To Reproduce
Steps to reproduce the behavior:

1. Create a repo-only PAT on an account that has member access to an organization repo where they are given the admin rights on the repository. (note: the user is not given admin access to the org)
2. Configure webhook on the repo, setup actions controller, install PAT
3. Create RunnerDeployment and HPA pointing at the repo

---
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: bar-runner
spec:
  template:
    spec:
      repository: foo/bar
      ## using eks / oidc
      # image: image:tag
      # serviceAccountName: svc-account-name
      # securityContext:
      #   fsGroup: 1000
---
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
  name: bar-hra
spec:
  scaleTargetRef:
    name: bar-runner
  scaleUpTriggers:
  - githubEvent: {}
  minReplicas: 0
  maxReplicas: 10

4. Trigger a workflow, webhook controller should identify the HRA (but fail to take action):

Found 1 HRAs by key     {"key": "foo/bar"}
Found 0 HRAs by key     {"key": "foo"}
no repository runner or organizational runner found     {"event": "workflow_job", "hookID": "332463031", "delivery": "37a4e5c0-591d-11ec-8c42-e1ea428feb2f", "workflowJob.status": "queued", "workflowJob.labels": ["self-hosted", "Linux", "x64"], "repository.name": "bar", "repository.owner.login": "foo", "repository.owner.type": "Organization", "enterprise.slug": "", "action": "queued", "repository": "foo/bar", "organization": "foo"}
Scale target not found. If this is unexpected, ensure that there is exactly one repository-wide or organizational runner deployment that matches this webhook event {"event": "workflow_job", "hookID": "332463031", "delivery": "37a4e5c0-591d-11ec-8c42-e1ea428feb2f", "workflowJob.status": "queued", "workflowJob.labels": ["self-hosted", "Linux", "x64"], "repository.name": "bar", "repository.owner.login": "foo", "repository.owner.type": "Organization", "enterprise.slug": "", "action": "queued"}

5. Cancel the workflow, controller should both find the HRA and do something:

Found 1 HRAs by key     {"key": "foo/bar"}
job scale up target is repository-wide runners  {"event": "workflow_job", "hookID": "332463031", "delivery": "b68560f0-5921-11ec-8d7a-9f951ff061e6", "workflowJob.status": "completed", "workflowJob.labels": [], "repository.name": "bar", "repository.owner.login": "foo", "repository.owner.type": "Organization", "enterprise.slug": "", "action": "completed", "repository": "bar"}
Patching hra for capacityReservations update    {"before": null, "after": null}
scaled bar-hra by -1

Expected behavior
I expect the HRA to scale up the RD.

Screenshots
n/a

Environment (please complete the following information):

• Helm Release - v0.15.1
• eks - v1.21

Additional context
This is weird.

Start by tracing the webhook controller's HRA lookup and scale-up handling, comparing the repository key used for scaleUp with the working scaleDown path. Reproduce the issue with the provided RunnerDeployment and HorizontalRunnerAutoscaler manifests and workflow events; done means a repository-scoped HRA is recognized and its RunnerDeployment scales up on a queued job.