CI: build cupy-cuda{12,13}x wheels on GH-hosted runners, gated behind /test - #10049

Pure verbatim copy of cuda-python's build-stage CI as the starting
point for CuPy's shared-infra port. SPDX headers stripped (CuPy
convention). CuPy-specific adaptations follow in separate commits so
reviewers can diff against the source.

Workflows:
- .github/workflows/ci.yml          (orchestrator)
- .github/workflows/build-wheel.yml (reusable wheel build)

Composite actions:
- .github/actions/fetch_ctk/         (downloads mini CTK from redist)
- .github/actions/install_unix_deps/ (apt deps on Ubuntu)
- .github/actions/sccache-summary/   (parses sccache stats JSON)

Helpers:
- ci/versions.yml                  (CTK build pins)
- ci/tools/fetch_ctk_redistrib.py  (component filter / relative_path)
- ci/tools/lookup-run-id           (find prior GHA run)
- ci/tools/env-vars                (per-job env var setup)

Source: NVIDIA/cuda-python @ ea0215fd095a6ae86af1b01b2c6c35f725cf4330

Refs: cupy#9794, cupy#9974

Refs: cupy#9794, cupy#9974

Sets NVCC env var so CuPy's install_build.get_nvcc_path() routes nvcc
invocations through sccache, the same way CC/CXX wrap gcc. Drops the
linux-only guard on the rapidsai/sccache install step and branches on
host-platform for URL triple + binary name; uname -m on Linux so the
same path works for the future linux-aarch64 matrix. Install to a
portable workspace-relative ./sccache_bin/, prepended to $GITHUB_PATH
so bare-name 'sccache' / 'nvcc' resolve on Windows (fetch_ctk already
puts $CUDA_PATH/bin on $GITHUB_PATH).

CIBW_ENVIRONMENT (platform-agnostic) holds the shared GHA-cache /
sccache wiring; CIBW_ENVIRONMENT_{LINUX,WINDOWS} hold only the
platform-specific paths (/host/+/project/ inside the manylinux
container vs cygpath/native on Windows).

cl.exe wrapping (cuda-python#1185-style shim) is NOT done; this covers
the dominant nvcc cost. Follow up only if Windows wins are modest.

Refs: cupy#9794

Two independent cleanups squashed (both previously reviewed):

- ci/tools/lookup-run-id was vendored verbatim from cuda-python for the
  planned nightly workflow (cupy#9974), which never landed in this PR;
  nothing on this branch calls it. Both artifact-fetch sites resolve
  artifacts by name via the Actions artifacts API. The nightly
  follow-up needs an adapted lookup anyway (this copy's --tag mode
  expects push-event CI runs of a kind this workflow does not produce).

- cibuildwheel evaluates CIBW_ENVIRONMENT with shell-style parsing on
  all platforms, so the unquoted Windows path lost its backslashes and
  the sccache disk level landed at C:Usersrunneradmin.cachesccache
  (visible in run logs). Single-quote the value so the path survives.

…kflows

Replaces the previous single-workflow orchestration (reviewed over five
design rounds; see PR discussion) with three workflows, each with a
one-sentence story:

  ci-trigger.yml  Turns /test comments from an OWNER/MEMBER into
                  ci:triggered label events, and keeps the label honest
                  on pushes/reopens.
  ci.yml          Builds wheels when a PR is vouched (labeled) or when a
                  merge lands (push); the push leg also dispatches
                  FlexCI in-run.
  flexci.yml      After a successful /test build run, dispatches FlexCI
                  with the recorded request.

Design bar: as safe as the old flexci.yml with the same UX -- not
safer -- except that the new wheel build stage's shared compile cache
must not be poisonable by vouched PR code, which is the single
requirement forcing /test builds into PR-scoped cache context.

/test flow: the trigger leg validates the comment (PR open, OWNER or
MEMBER, explicit target), records the raw event payload as a
dispatch-request-<pr>-<head_sha> artifact, and bounces the ci:triggered
label with a GitHub App token (GITHUB_TOKEN label events do not trigger
workflows). The labeled build runs in the PR's cache scope (writes
isolated per PR, restores fall back to base/default scope -- since
GitHub's 2026-06-26 change, untrusted default-scope contexts are cache
read-only anyway) from the event-pinned merge commit, tags its wheel
artifacts with the PR number (same-head PRs against different bases
never share wheels), and uploads a build sentinel only when every build
succeeded. flexci.yml reacts to the run's completion: sentinel =
liveness (no-op label runs can never dispatch); PR identity comes only
from trusted API metadata (pulls?head=<head repo>:<branch>); per
candidate PR it requires a request recorded by a default-branch run of
this repository (fork runs cannot forge that provenance), and verifies
the PR still points at the tested head and base before feeding the
recorded payload to flexci_dispatcher.py unchanged.

Post-merge: push events (main, v*, hotfix-*) are trusted, carry
secrets, may write this branch's cache scope, and are the dispatcher's
native input -- so build and dispatch live in one run with plain needs:
ordering, no artifacts, no relay. The guard maps the pushed commit to
its merged PR to honor skip-ci, and skips branch deletions. Push runs
have no shared concurrency group: a burst of merges must not cancel
intermediate runs, each of which carries its own dispatch.

A push to a PR (synchronize) cancels any in-flight labeled build via
the shared ci-build-<PR> concurrency group and clears the stale label;
adding an existing label fires no event, so the bounce removes it
first. All artifact uploads set overwrite so "re-run all jobs" stays
viable across immutable v4+ artifact attempts.

TEMPORARY: flexci.yml carries a legacy pull_request_target(closed)
dispatch job for bases not yet backported the new push workflow
(allowlist, currently v14); each allowlist entry is removed by the same
PR that backports the workflows to that base.

The reusable build workflow no longer receives secrets: it needs none,
and labeled runs of same-repo PRs would otherwise expose repository
secrets to PR code.

Requires (already provisioned or requested): the ci:triggered label;
GitHub App cupy-ci-trigger (Issues:R/W, webhook off) with repository
variable CI_TRIGGER_APP_ID and secret CI_TRIGGER_APP_PRIVATE_KEY;
secrets.FLEXCI_WEBHOOK_SECRET; CUPY_CI_GITHUB_TOKEN on the FlexCI side.
The .pfnci wheel fetch (PR cupy#10058) must pin artifact producers and use
the PR-tagged names; the v14 backport of these workflows lands in
lockstep with this PR's merge.

The App credentials (CI_TRIGGER_APP_ID variable and
CI_TRIGGER_APP_PRIVATE_KEY secret) are provisioned in a deployment
environment rather than at repository level, so only jobs declaring
`environment: ci-trigger` can read them. The environment's branch
policy allows main only -- the ref issue_comment runs execute on --
which additionally shuts out every other context. Each /test records
a deployment to the environment as a side effect (a useful audit
trail).

Instead of hard-coding which release bases still lack the new push
workflow (and paying for it with a coordinated main-side cleanup PR
plus a double-dispatch window after each backport), probe the merge
commit's own tree: the push run for a merge uses exactly those files,
so "new ci.yml present" means that run dispatches and the legacy job
stays quiet. The handoff is atomic -- the very backport merge that
brings the workflow to a base is already dispatched by its own push
run -- so double dispatch and missed dispatch are impossible by
construction, and the job self-retires (delete whenever, no timing
constraint).

The probe only applies to bases the push branch filter can match
(v*/hotfix-*, never crossing '/' -- Actions glob semantics, unlike
bash); merges into any other base always dispatch legacy-style, which
also restores the old any-base behavior for workflow-less branches the
v14 allowlist never covered.

Reviewed by Codex over three rounds (round 1: push-filter gating;
round 2: '/' glob semantics; round 3: no material findings).

actions/checkout v7 (backported to every maintained line on 2026-07-20,
which is what broke the old flexci.yml on main via the floating v4 tag)
refuses to check out fork-PR code -- head SHA, refs/pull/*, and
merge_commit_sha included -- from pull_request_target and workflow_run
workflows unless the step sets allow-unsafe-pr-checkout: true.

This file's pinned v6.0.3 predates the guard, so nothing is broken
today, but the pin will not stay frozen forever (renovate is active).
Adopt v7.0.1 in this file now and make the two affected checkouts'
security posture explicit:

- the workflow_run untrusted checkout is data only (the dispatcher
  executes from the trusted checkout and merely json-loads
  config.tags.json from it);
- the legacy-dispatch checkout only ever sees merged PRs, i.e.
  reviewed code already landed on the base branch.

The trusted default self-checkout stays unflagged on purpose: the
guard exempts it, and keeping the flag off means any future
explicit-ref checkout added here gets refused until reviewed.

Other workflows keep their current pin: their events (pull_request,
push) are outside the guard's scope on any checkout version.

Reviewed by Codex (plan round: agreed, checkout-site inventory
independently re-derived; diff round: no material findings, pin SHA
and v7.0.1 delta independently verified).

The three CI workflows declared their write scopes (pull-requests,
statuses, issues) at the workflow level, so every job -- including the
untrusted-PR-code build jobs and the reusable-workflow callers --
received them even though only the FlexCI-dispatch and label-hygiene
jobs write anything. Move each scope down to the job that uses it and
default every workflow to contents:read, so a token leak from any build
or PR-controlled job cannot write.

- ci.yml: default contents:read; guard +pull-requests:read (ci-guard.sh
  reads commits/<sha>/pulls on the push leg); dispatch-flexci
  +pull-requests:write, statuses:write (flexci_dispatcher.py). ci-vars
  and the two reusable build callers pin contents:read explicitly; the
  sentinel and status-check jobs inherit the read-only default.
- ci-trigger.yml: default contents:read; test-request pull-requests:read
  (the ci:triggered label bounce uses a separate GitHub App token, not
  GITHUB_TOKEN); hygiene issues:write.
- flexci.yml: default contents:read; dispatch actions:read +
  pull-requests:write + statuses:write; legacy-dispatch pull-requests:write
  + statuses:write (no actions:read -- it reads no run artifacts).
- build-wheel.yml is unchanged: it already declares its own contents:read
  ceiling (a reusable workflow does not inherit the caller's permissions,
  so each file is self-contained).

Addresses seberg's review: the guard and ci-vars per-job permission
suggestions are applied verbatim.

Reviewed by Codex (working-tree diff: the token scopes needed by each
affected job are preserved, no regression).