Route trusted Linux builds to managed runners

[wesm]

Same-repository pull-request branches are controlled by repository collaborators and should use organization-managed Linux capacity. Fork pull requests remain arbitrary code—even when the author is an organization member—and must continue to use GitHub-hosted runners.

Each PR now triggers only pull_request, so required checks are associated with the current PR revision. The dispatcher calls a main-pinned reusable workflow, and that immutable workflow independently requires both the head and base repositories to equal github.repository before selecting the managed public fleet. The caller supplies no runner or trust input.

The organization runner policy restricts access to the exact main-branch reusable workflows. Main pushes use the managed Linux fleet; Windows, macOS, ARM Linux, tags, and fork PRs retain their hosted runners.

[roborev-ci]

roborev: Combined Review (6c73437)

Validation checks may not reliably gate same-repository PR revisions due to pull_request_target check association.

High

• .github/workflows/ci-pr.yml:8 (also bench-pr.yml:17 and desktop-artifacts-pr.yml:16) — Same-repository validation runs only through pull_request_target, whose checks are associated with the base commit. Checking out refs/pull/.../merge does not change that association, while the corresponding pull_request job is skipped. Run required validation from pull_request using the immutable reusable workflow, or explicitly report the result against the PR head/merge SHA.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 11m23s

[roborev-ci]

roborev: Combined Review (2f7f273)

Medium-severity runner-routing gap remains; fork-proposed dispatcher workflows could target the managed runner directly.

Medium

• Location: .github/workflows/ci-pr.yml:6, .github/workflows/bench-pr.yml:6, .github/workflows/desktop-artifacts-pr.yml:6
• Problem: Forks can modify these pull_request dispatcher workflows and add jobs targeting kenn-linux-x64-public, bypassing routing checks in the main-pinned reusable workflows. Approved fork workflow code may execute under repository policy.
• Fix: Restrict the managed runner group to the exact reusable workflow paths pinned to refs/heads/main, or use another base-controlled dispatch mechanism.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 13m27s

[wesm]

This finding is already mitigated by the organization runner-group policy and does not require a workflow change here.

I verified the live ci-runners-public runner group:

• restricted_to_workflows is true.
• The allowlist contains the reusable implementations pinned to refs/heads/main, including kenn-io/agentsview/.github/workflows/ci.yml@refs/heads/main, bench.yml@refs/heads/main, and desktop-artifacts.yml@refs/heads/main.
• It does not contain ci-pr.yml, bench-pr.yml, or desktop-artifacts-pr.yml.

A fork can modify a pull_request dispatcher and request kenn-linux-x64-public, but that dispatcher workflow is not authorized to use the runner group, so GitHub will not assign one of these runners. Only the main-pinned reusable workflow can acquire the managed runner, and that workflow independently requires both the PR head and base repositories to equal github.repository; otherwise it selects ubuntu-latest.

This is the layered boundary intended by the organization runner policy: selected-workflow enforcement prevents direct dispatcher access, while the reusable workflow independently derives admission from immutable event context. The finding would become valid if restricted_to_workflows were disabled or a fork-controlled workflow reference were added to the allowlist.