fix: select reusable staging sweep run

[cquil11]

Summary

• select the newest artifact-bearing full-sweep run from any commit still in the source PR
• skip successful check-only/reuse-gate runs that produced no staging artifacts
• allow an explicit run ID from an earlier commit that remains in the PR history
• use the existing cross-repository PAT for authorization and PR comments

Root cause

The initial selector filtered to the current PR head and chose the newest successful run before checking artifacts. PR #2157 therefore selected a successful no-op reuse check and could not fall back to the prior completed sweep. GitHub also reduced the issue_comment GITHUB_TOKEN to read-only for the fork-PR context, so the failure comment returned 403.

Validation

• actionlint .github/workflows/stage-results.yml
• git diff --check
• zizmor .github/workflows/stage-results.yml
• verified PR [WIP] Add GB300 DeepSeek-V4 dynamo-sglang agentic recipes #2157 commit history contains run 29181694248 head SHA
• verified run 29181694248 has unexpired changelog-metadata and bmk_agentic artifacts

[claude]

This PR touches CI auth/permissions (drops the job-level permissions: block and swaps three github-token usages from github.token to secrets.INFX_FRONTEND_PAT), so I'd like a human to sign off. No bugs were found by the review pass — the run-selection refactor looks internally consistent and the finder's concern about removing bilingual failure comments was examined and ruled out (the remaining bilingual comments cover user-visible paths; the removed ones fired only when core.setFailed was already going to surface via the workflow status).

Extended reasoning...

Overview\n\nSingle-file change to .github/workflows/stage-results.yml. Two categories of edits: (1) refactor of the /stage-results source-run selector — replaces the head-SHA + belongs-to-PR filter with an in-PR commit-set membership check, moves all gating (path, event, label-timing, status, artifact presence) into a single validateRun helper, and iterates all completed runs on the PR branch via github.paginate until one with usable artifacts is found; (2) token/permissions change — removes the job-level permissions: block and points the three actions/github-script steps at secrets.INFX_FRONTEND_PAT instead of github.token.\n\n### Security risks\n\nThe workflow triggers on issue_comment and dispatches to a sibling repo, so it's inherently sensitive. The actor gate (write/maintain/admin via getCollaboratorPermissionLevel) and the command regex are unchanged, so the authorization surface is the same. The PAT swap is the load-bearing risk: INFX_FRONTEND_PAT was already used by the cross-repo dispatch step, so scope isn't expanding, but it's now also the identity that posts the ack comment and reads runs/artifacts/timeline/commits. A human should confirm the PAT's scopes are still appropriate and that removing the job-level permissions: block (now inheriting the top-level permissions: {}) doesn't break any step that still relies on GITHUB_TOKEN — spot-checking the diff, none of the remaining calls use github.token, so this should be fine.\n\n### Level of scrutiny\n\nHigh — CI workflow touching auth tokens on a comment-triggered dispatcher is exactly the shape I'd rather not shadow-approve, even when the diff is small and the rationale is clear. Blast radius on a mistake here is repo-wide.\n\n### Other factors\n\nRoot cause and validation (actionlint, zizmor, artifact spot-check on run 29181694248) are documented in the PR description. The candidate concern about removed bilingual PR feedback on the label-predating and missing-changelog-metadata paths was ruled out by the finder pass — those paths now surface only via core.setFailed, which is a UX regression at worst, not a correctness bug.