GitHub PR stages can't use an existing fork-network sibling (e.g. silug/puppet-selinux for pupmod-voxpupuli-selinux)

[silug]

Problem

GitHubPRForker#user_fork_of_repo finds "the user's fork" by listing the direct forks of the target repo and matching on owner. That works for normal simp/* repos, but not for repos that are themselves forks, like simp/pupmod-voxpupuli-selinux (a fork of voxpupuli/puppet-selinux, default branch simp-master).

Concretely: silug/puppet-selinux is a fork of the network root voxpupuli/puppet-selinux, which makes it a sibling of simp/pupmod-voxpupuli-selinux, not a direct fork of it — so user_fork_of_repo('simp/pupmod-voxpupuli-selinux', 'silug') returns nil even though the user has a perfectly usable fork in the network.

From there, ensure_fork POSTs /repos/simp/pupmod-voxpupuli-selinux/forks and one of two things happens:

1. GitHub creates a brand-new direct fork (silug/pupmod-voxpupuli-selinux — the modern fork-a-fork behavior when the name is free). The pipeline then works end-to-end, but through a redundant second fork instead of the user's existing one. There's also a first-run race: fork creation is async, and with github_api_delay_seconds: 1 the push/PR stages can hit the fork before it exists (heals on re-run).
2. GitHub returns the existing sibling fork (the legacy one-fork-per-network dedup). The push then lands in silug/puppet-selinux, but ensure_github_pr fails: existing_pr dereferences the nil fork lookup (repo_fork.full_name → NoMethodError) when the target repo has open PRs, and create_pr raises ERROR: no fork of '...' found for user ... otherwise.

Either way, the sync never uses the user's existing fork of the upstream, and in case 2 the PR stage crashes.

Proposed fix

Make user_fork_of_repo fork-network-aware. After the direct-forks check misses:

1. Resolve the network root: upstream_repo.fork ? upstream_repo.source : upstream_repo (e.g. voxpupuli/puppet-selinux).
2. Probe the user's candidate repos by name — #{fork_user}/#{upstream_repo.name} and #{fork_user}/#{root.name} (e.g. silug/puppet-selinux).
3. Accept a candidate iff it's a fork whose source is the same network root.

With that, ensure_fork returns the existing sibling fork without creating anything, the feature branch is pushed there, and create_pull_request opens the PR with head user:branch against the simp repo's base branch — GitHub allows PRs between any repos in the same fork network, and the base branch is already correct (the dynamic inventory records the repo's real default branch, simp-master).

existing_pr should also be hardened against a nil fork lookup regardless (it currently NoMethodErrors instead of reporting a useful failure).

Context

Found while rolling out the 20260811-reference-md session (#58): pupmod-voxpupuli-selinux is in the dynamic inventory via the include_forks allow-list, so its GitHub stages will exercise this path as soon as the repo-side CI problems are sorted out.

[silug]

More context on this repo's readiness (beyond the fork-network problem above):

• The other blocker is Update to upstream v6.0.0 pupmod-voxpupuli-selinux#15 (update to upstream v6.0.0), still open.
• simp-master currently has no .github/workflows/ directory at all, so the repo has no Actions CI yet. That also means workflow-merge sessions are a no-op there (the merge stage only refreshes files that exist in both the repo and the template chain) — the first pr_tests.yml would have to come from the apply_puppet_role/bootstrap path, or be added by hand.
• Even with Added logic to exclude tpm from getting el 8 and higher os updates an… #15 merged and the fork-network fix in place, the repo follows upstream Vox Pupuli conventions (msync-managed files, upstream Gemfile/Rakefile), so the simp pupmod baseline probably doesn't apply cleanly as-is. Expect it to need per-repo overrides or a scoped session before puppetsync can manage it.

For now it's been dropped from the dynamic inventory's include_forks allow-list on the #58 branch; re-adding that line is the switch to flip once the above is sorted.

[silug]

Re-adoption of pupmod-voxpupuli-selinux into include_forks is now tracked as #86 — this issue is its remaining blocker.

The repo-side half is cleared: after the 6.0.0 modernization its PR Tests run is green on all 9 jobs (including the full OpenVox 8 / Ruby 4.0-preview spec matrix), so the "its CI isn't green yet" clause in the github-org.yaml comment no longer applies. Fixing the fork-network lookup here is what's left before it can be synced.