PyTorch fixes CI runner-determinator to use base ref, not PR head
A stale script checkout caused CI jobs to become unroutable after label changes.
The issue stemmed from the `_runner-determinator.yml` workflow checking out `.github/scripts/runner_determinator.py` from the pull request head commit (`github.event.pull_request.head.sha`). When a PR branch predates changes to the script—such as the recent rename of the prefix from `lf.` to `lf-` or the removal of EC2 build paths in #189113/#189171—the stale copy emitted a runner-label prefix (e.g., `lf.l-x86iavx512-8-64`) that main's build workflow no longer recognized. This left the job stuck in an unroutable state, unable to be assigned to any fleet.
The fix, introduced in commit 8417736, splits the checkout into two parts: the determinator script is now checked out from the default branch (main) or the merge commit for pull request events, ensuring it is always up-to-date with the current workflow logic. Meanwhile, `.ci/docker` continues to use the PR head's SHA via a separate sparse checkout under `pr-head/` to preserve the correct CI-docker hash. Additionally, the workaround that probed `--help` for `--workflow-name` support is removed, as the script is no longer stale and always supports the flag. This patch ensures reliable CI routing and reduces maintenance overhead.
- The runner-determinator script was checked out from PR head, causing stale copies after prefix renames (e.g., 'lf.' to 'lf-') and EC2 removal.
- Stale scripts emitted unrecognizable runner labels, leaving CI jobs stuck unroutable.
- Fix splits checkout: determinator uses base ref (main/merge commit); .ci/docker uses PR head via separate sparse checkout.
Why It Matters
Eliminates a subtle CI failure mode, ensuring PyTorch's build system reliably routes jobs and developer time isn't wasted.