feat(ci): refuse fork-authored code before checkout, on every self-hosted job

[ywatanabe1989]

What

Every self-hosted job here that runs actions/checkout now refuses fork-authored pull requests before checkout. Five workflows: pytest-matrix, import-smoke, quality-audit, rtd-sphinx-build, self-test.

No repo or org settings are changed by this PR.

Why

These jobs run bare on shared University of Melbourne HPC nodes — no container, no overlay, two concurrent jobs sharing one $HOME (measured by scitex-hpc on the CI supervisor allocation, job 28161762, spartan-bm062). uv pip install -e . alone executes a pull request's own build-backend hooks there, and rtd-sphinx-build executes the fork's conf.py as plain Python.

Operator, 2026-07-30: 「大学の資源を外部の人にも使わせる形になったら一発でアウトなのでそれはだめですね」

Why refuse rather than re-route to ubuntu-latest

That was the obvious fix and it is forbidden. Operator mandate 2026-07-14, enforced as PS-169: 「github側のランナーというのは本当にもう一切使わないでください…強制です、例外なしです」.

Two mandates, nothing in the intersection — so fork-authored code is refused, not relocated. The durable resolution is a runner we own (neither GitHub's nor the university's); that is a hardware conversation, not this patch.

Shape of the guard

• First step, ahead of actions/checkout — checkout is what first puts fork content on the node, so a guard after it is a report, not a barrier.
• Fails, does not skip — a skipped job's check can be reported as successful to branch protection, which is a red that looks green.
• Names the remedy (gh pr checkout + push to a review branch) — an error that only says what broke is half-written.
• Job names untouched, so every repo's required status checks keep reporting.

Scope correction worth recording

The first search reported one self-hosted runs-on. An unfiltered re-run found nine, across seven files — eight rows had been dropped with no truncation marker. auto-merge-to-develop and cla are excluded because they check out nothing (cla measured 2026-07-30 on scitex-app), so no fork code runs there.

Tests

tests/test_fork_guard.py derives the covered set rather than listing it: it parses every workflow, selects jobs that are self-hosted and check out, and requires the guard on exactly those. Add a self-hosted workflow that checks out a PR and these tests go red on that change — a hardcoded list would go stale silently and keep passing. It also asserts locally that no job resolves to a hosted image, so a future "just use ubuntu-latest for forks" cannot land here quietly.

Mutation-probed, each restoring the tree afterwards:

mutation	result
guard moved after checkout	test_guard_step_precedes_every_checkout fails
predicate relaxed to head.repo.fork	test_guard_predicate_is_the_sanctioned_one fails
a job flipped to ubuntu-latest	selector count + PS-169 arm fail (2 tests)

Baseline and post-restore: 74 passed.

What this does NOT do

For pull_request, GitHub runs the workflow definition from the PR's own head. A hostile fork can therefore edit the caller's ci.yml to bypass these reusable workflows entirely and declare its own self-hosted job. This closes the default path; it is not a boundary.

The boundary is the fork-PR approval policy — measured all_external_contributors on 74 of 74 public scitex-ai repos and as the org default for new repos (2026-07-30), so no external contributor's workflow runs without a maintainer's click. The README now says plainly what that click means, and gives the safe alternative: adopt the branch into the repo and open a same-repo PR.