ci: keep public repo gates on hosted runners

[will-wang-opus]

What & why

This repo is public. Two of its gates were broken by assumptions that only hold for our private repos.

1. actions-pinned-check never ran. The job declared runs-on: opus-runner-standard, a self-hosted runner. It has never once been assigned a runner in this repo — every run sat queued with runner_name="" until GitHub auto-cancelled it at the 24h ceiling (run 31613024589, run 31847701356). The identical gate finished in 8 seconds when it ran on ubuntu-latest (run 31595196968).

Beyond the hang, a public repo should not target self-hosted runners at all: a pull request from a fork runs untrusted code, and a self-hosted runner would execute it on our own infrastructure with whatever state the previous job left behind. This is GitHub's documented guidance. The gate is shell-only — a grep over .github/** — so it needs nothing a hosted runner lacks.

2. check-pr-basics failed on every PR. thehanimo/pr-title-checker was fetching pull_request_title.json through the GitHub contents API, which this job cannot reach. The file lives in this repo and the job already checks it out, so local_configuration_path reads the same config straight off the working tree. LABEL.name is empty in the config, which short-circuits the action's label calls, so that fetch was its only API call — the gate is now self-contained.

Verified locally against this branch: the pinned-actions grep reports all uses: refs SHA-pinned, and test_pr_title.py passes.

AI coding brief

• Original request: Get the check gate running on this repo — it had been queuing for 24h and dying without executing a step — and keep the public repo off self-hosted runners.
• Manual interventions: An earlier attempt routed the gate through a shared composite action while keeping the self-hosted runner; that was reverted (ci: unblock pinned-actions gate and pr title check #10 closed) once it was clear the runner, not the gate's implementation, was the problem.
• Retro: "The check is failing" and "the check never started" look identical in the PR UI but have nothing in common — reading runner_name and the queued→cancelled timestamps off the jobs API separates them in one call and would have skipped the first attempt entirely. Worth stating a repo's visibility up front too: public vs private is what made both of these defaults wrong.