Org-level self-hosted runner never dispatched despite correct runner group repo access

---

Body:

Summary

A self-hosted runner registered at the organization level and assigned to a runner
group with explicit repository access was never picked up by the job dispatcher.
The job remained in "Queued" state indefinitely. No runner_group_id was ever assigned
to the queued job, suggesting the internal broker did not resolve the runner
within the scope of the target repository.

The issue was worked around by re-registering the runner directly at the
repository level, after which the job was dispatched immediately.

Environment

• GitHub plan: GitHub Team
• Runner OS: Ubuntu 24.04.4 LTS
• Runner version: 2.334.0
• Runner registration scope: Organization (mims-devops)
• Runner group: rsm
• Target repository: mims-devops/mims-monorepo
• Broker protocol: V2 (useV2Flow: true, broker: broker.actions.githubusercontent.com)

Steps to reproduce

1. Register a self-hosted runner at org level (mims-devops).
2. Create a runner group named rsm.
3. Add the target repository (mims-monorepo) to the runner group's allowed repositories.
4. Trigger a workflow in that repository with runs-on: [self-hosted, "rsm"].
5. Observe: job stays in "Queued" indefinitely.

Expected behavior

The dispatcher resolves the runner group membership and assigns the job to the
available org-level runner within the allowed repository scope.

Actual behavior

The job is never dispatched. Inspecting the job via API
(GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs) shows runner_group_id: null
and runner_name: null for the entire queue duration.

The runner was online and idle throughout (confirmed via
GET /orgs/{org}/actions/runners).

Example run: https://github.com/mims-devops/mims-monorepo/actions/runs/25923090140

Error message

No error message is displayed. The job stays in "Queued" state indefinitely
and is never assigned to a runner. Inspecting the job via API confirms
runnerId: null, runnerName: null, runnerGroupId: null throughout the entire
queue duration. The only way to stop it is to cancel the run manually.

Hypothesis

Possible inconsistency in the broker V2 protocol (useV2Flow: true,
serverUrlV2: broker.actions.githubusercontent.com) when resolving org-level runner
group membership against per-repository access grants.
The runner group permissions appear correct from both the UI and API, but the
dispatcher does not associate the runner with the target repository at dispatch time.

Workaround

Re-register the runner at repository level instead of org level.
Job dispatching works correctly with a repo-level runner using identical labels
and workflow configuration.

Additional context

• Runner group repository access was verified both via UI
  (Org Settings → Actions → Runner Groups → rsm → Repository access)
  and via API (GET /orgs/{org}/actions/runner-groups/{id}/repositories).
• No error message is surfaced to the user — the job simply never leaves "Queued".
• Removing and re-adding the repository to the runner group did not resolve the issue.
• The runner .runner config confirms useV2Flow: true and
  serverUrl: pipelinesghubeus24.actions.githubusercontent.com.

---

URL run di esempio (per il campo del form):
https://github.com/mims-devops/mims-monorepo/actions/runs/25923090140

Messaggio di errore (per il campo del form):
No error message is displayed. The job stays in "Queued" state indefinitely
and is never assigned to a runner. Inspecting the job via API confirms
runnerId: null, runnerName: null, runnerGroupId: null throughout the entire
queue duration. The only way to stop it is to cancel the run manually.

Start with the reproduction steps and the runner’s .runner configuration, especially useV2Flow and serverUrlV2. Inspect the listed runner and job APIs for runner_group_id, runnerId, and runnerName while comparing organization-level and repository-level registration; done when the dispatch behavior is explained or a reproducible fix is identified.