Re-add pupmod-voxpupuli-selinux to include_forks (CI is green as of 6.0.0; blocked on #83)

Problem

pupmod-voxpupuli-selinux was included in the dynamic inventory's include_forks allow-list at one point, but had to be dropped. data/sync/repolists/github-org.yaml records why:

  # Forks that simp actively maintains:
  # (pupmod-voxpupuli-selinux is deliberately absent for now: its CI isn't
  # green yet, and puppetsync can't open PRs from a fork-network sibling
  # like silug/puppet-selinux until simp/puppetsync#83 is fixed)
  include_forks:
    - rubygem-simp-rspec-puppet-facts

The first of those two blockers is now cleared. The repo was modernized and released as simp-6.0.0 on 2026-08-12, and its PR Tests run on update-to-v6.0.0 (run 31528560477, 2026-08-11) came back green on all 9 jobs:

The 6.0.0 release also brought it onto the fleet toolchain: openvox >= 8.19.0 < 9.0.0, puppetlabs/stdlib >= 9.0.0 < 10.0.0, the openvox gem, voxpupuli-test ~> 14, and EL9/EL10 + Fedora/Debian/Amazon in metadata.json.

So the remaining blocker is #83 (fork-network sibling forks), not the repo.

Why it's worth adopting

Being outside the sync set has a concrete cost right now: the repo missed the ghcr RPM container fix (#80), which landed in all 71 in-scope module repos on 2026-08-11. Its release_rpms.yml still resolves docker.io/simpproject/simp_build_${build_container_os}:latest, so when simp-6.0.0 was tagged on 2026-08-12 both dispatched RPM builds failed with the original NameError: uninitialized constant JSON::Fragment — a defect that was already fixed everywhere else. Its tag_deploy.yml also still carries the hardcoded [centos7, centos8] matrix (tag_deploy.yml:157-160), so it needs #84 too.

In other words this is a repo SIMP actively releases, and it is now the one that silently misses fleet-wide release-pipeline fixes.

Proposed change

Once #83 is fixed, re-add it and drop the explanatory comment:

  include_forks:
    - rubygem-simp-rspec-puppet-facts
    - pupmod-voxpupuli-selinux

Then run a session against it alone before including it in a fleet-wide run.

Things to get right on first sync

1. #83 must land first. Otherwise the PR stage either creates a redundant direct fork or crashes in existing_pr / create_pr, depending on which fork-dedup behavior GitHub applies.
2. The default branch is simp-master, not master. The dynamic inventory already records real default branches, so this should be automatic — but the repo also still has a stale master branch (last CI run 2026-06-18) plus puppet3 and remove-docker-nodesets, so it is worth confirming the session targets simp-master.
3. None of the baseline files currently carry the puppetsync managed marker. Gemfile, Rakefile, .rubocop.yml, and .puppet-lint.rc are all hand-maintained fork-era files, so the first sync will be a much larger diff than a typical module's. Review it by hand rather than auto-approving.
4. It is a fork with a live upstream, and that is a standing tension. voxpupuli/puppet-selinux is still active (last push 2026-05-20). Every baseline file puppetsync takes ownership of is one more conflict when merging upstream. Worth deciding deliberately how much of the baseline should apply here — possibly a reduced set — rather than treating it as a normal module. This interacts with the longer-term question of retiring the fork in favor of consuming upstream directly.
5. The module namespace is vox_selinux, not selinux (re-namespaced to coexist with pupmod-simp-selinux). Any template that derives a class or namespace from the repo name will get this wrong.
6. pupmod-simp-haveged has the same exposure — also a SIMP-maintained fork outside the sync set. Worth checking whether it belongs in include_forks in the same pass, though its CI is in worse shape (its rubocop job is if: false and its fork-era .rubocop.yml requires a missing rubocop-i18n).

Not a duplicate of #83

#83 is the tooling fix in GitHubPRForker#user_fork_of_repo. This issue is the adoption task that #83 unblocks, and the place to record the repo-side prerequisites now that CI is green.

Wait for #83, then inspect data/sync/repolists/github-org.yaml and the existing include_forks handling. Run a session against pupmod-voxpupuli-selinux alone, confirming it targets simp-master and reviewing the larger baseline diff manually. Done means the repository is re-added and the isolated sync completes safely without mishandling its fork or vox_selinux namespace.