ci: confirm visible_to_repository's format before narrowing the watchdog's runner-group walk

[wallstop]

Context

stuck-job-watchdog.yml enumerates all organization runner groups:

orgs/${OWNER}/actions/runner-groups?per_page=100

It previously filtered with visible_to_repository=<repo name>. That was removed
in #331 rather than corrected, because the correct value could not be
established:

• the REST docs type visible_to_repository as "string" and state no format,
  so repository name and numeric repository id are both plausible and
  not distinguishable from the documentation;
• the endpoint requires admin:org, which no token available in that workspace
  carried, so the two forms could not be compared against a live response;
• both wrong-guess outcomes (a 4xx, or an empty list) land in the watchdog's
  fail_closed, so guessing wrong fails every one of its 288 daily runs while
  reporting a credential or outage problem that does not exist.

The organization registers a single runner group ("Default") today, so the
filter would select exactly what the unfiltered call already returns. Removing it
cost nothing and removed a live failure risk.

Why this needs revisiting eventually

Enumerating all groups over-counts capacity if a second, restricted group is
ever added. The watchdog cancels runs it believes are dispatcher-stuck, and
over-counting capacity is precisely what could turn a legitimately queued run
into a wrongful cancel. The group names are already logged to the step summary
for this reason.

Trigger and required work

Act when a second group name appears in the watchdog's Organization runner groups: summary line.

1. With an admin:org token, call the endpoint three ways and record the
   responses: unfiltered, visible_to_repository=<repo name>, and
   visible_to_repository=<numeric repo id>.
2. Narrow the walk using whichever form the live response confirms, not
   whichever the docs seem to suggest.
3. Add a fixture row to validate_stuck_job_watchdog covering a group that is
   not visible to this repository, so the narrowing is pinned.

Until then the current unfiltered walk is correct and safe.

Original finding by GitHub Copilot on #331.

[wallstop]

Superseded by #338 — and the premise this issue rested on was wrong.

This issue said the organization registers a single runner group, so dropping the visible_to_repository filter cost nothing, and asked that the walk be narrowed only if a second group ever appeared. The first production run of the merged watchdog showed the second group was already there:

Organization runner groups: Default, ambiguous-interactive-organization-builds, Default

So the trigger condition this issue described had already fired before it was written.

#338 narrows the walk without needing the admin:org probe this issue asked for. The group objects returned by the list endpoint already carry visibility; all needs no further call, and selected groups resolve against the group's own repositories endpoint compared with github.repository_id — numeric ids on both sides, no format to guess. That answers the original question by not asking it.

I'll close this once #338 merges.