chore: use INFERENCEX_OFFICIAL_RO_HF_TOKEN secret in workflows

[cquil11]

Switch the HF token secret reference from secrets.HF_TOKEN to secrets.INFERENCEX_OFFICIAL_RO_HF_TOKEN in benchmark-tmpl.yml, profile.yml, and speedbench-al.yml.

---

Note

Low Risk
Limited to CI secret wiring; jobs will fail to access gated models if the new secret is missing or invalid, with no application auth or runtime code changes.

Overview
Benchmark, profile, and SpeedBench AL GitHub Actions workflows now source HF_TOKEN from secrets.INFERENCEX_OFFICIAL_RO_HF_TOKEN instead of secrets.HF_TOKEN. The runtime env name is unchanged; only which repository secret backs Hugging Face Hub access in CI is updated (including the reusable benchmark-tmpl.yml template used by downstream benchmark jobs).

^{Reviewed by Cursor Bugbot for commit 707d0c6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

🔴 The PR title chore: use INFERENCEX_OFFICIAL_RO_HF_TOKEN secret in workflows (plural) implies the migration covers all workflows, but .github/workflows/speedbench-al.yml (line 76) still reads HF_TOKEN: ${{ secrets.HF_TOKEN }} after this PR. If the old HF_TOKEN secret is decommissioned/rotated, SPEED-Bench AL will silently get an empty token (missing GitHub Actions secrets expand to an empty string) and Hugging Face auth will fail only there while benchmark-tmpl.yml and profile.yml succeed. Suggest including the same one-line swap in speedbench-al.yml in this PR.

Extended reasoning...

What the bug is. This PR migrates the Hugging Face token reference from secrets.HF_TOKEN to secrets.INFERENCEX_OFFICIAL_RO_HF_TOKEN in two workflow files (benchmark-tmpl.yml:92 and profile.yml:34), but a third workflow under .github/workflows/ — speedbench-al.yml — still references the old secret at line 76 (HF_TOKEN: ${{ secrets.HF_TOKEN }}). The PR title ("use INFERENCEX_OFFICIAL_RO_HF_TOKEN secret in workflows", plural) and the lack of any caveat in the description both read as a repo-wide migration, so leaving one workflow behind is almost certainly an oversight rather than an intentional carve-out.

Why this matters. A missing GitHub Actions secret silently expands to the empty string in ${{ secrets.* }} interpolation — Actions does not fail the step or warn. So if HF_TOKEN is decommissioned (or rotated and not re-added under the old name) once the new secret is in place, the SPEED-Bench AL workflow will run with HF_TOKEN="" and any gated/private Hugging Face access (e.g. model downloads that require auth) will start returning 401s. The migrated workflows will keep working because they read the new secret, so the failure mode is asymmetric and easy to overlook until someone re-triggers SPEED-Bench AL.

Why existing code doesn't prevent it. There is nothing in the workflow that asserts the token is non-empty before use — the token is exported as an env var and consumed downstream by the HF client, which only fails at the point of a gated network call. The job-level env block in speedbench-al.yml was added recently (commit d8933d7 / PR #1650, immediately prior to this PR's HEAD 535567d), so it existed at the time of this migration and was simply missed.

Step-by-step proof.

1. Check out this PR (HEAD = 535567d).
2. grep -n 'secrets.HF_TOKEN' .github/workflows/*.yml returns exactly one hit: .github/workflows/speedbench-al.yml:76: HF_TOKEN: ${{ secrets.HF_TOKEN }}.
3. grep -n 'INFERENCEX_OFFICIAL_RO_HF_TOKEN' .github/workflows/*.yml returns benchmark-tmpl.yml:92 and profile.yml:34 only.
4. Assume the secret HF_TOKEN is removed from the repo's Actions secrets (the natural follow-up to a migration). When speedbench-al.yml runs, ${{ secrets.HF_TOKEN }} evaluates to '' (documented GitHub Actions behavior for missing secrets), so the job runs with HF_TOKEN=. Any gated HF download then fails with a 401 (or with anonymous-rate-limit errors), while the other two workflows authenticate normally with the new token.

How to fix. One-line change in .github/workflows/speedbench-al.yml:76:

-  HF_TOKEN: ${{ secrets.HF_TOKEN }}
+  HF_TOKEN: ${{ secrets.INFERENCEX_OFFICIAL_RO_HF_TOKEN }}

Including it in this PR keeps the migration atomic and avoids a stale reference outliving the secret it points at. If keeping HF_TOKEN on the old secret is intentional (e.g. a different scope is needed for SPEED-Bench AL), it'd be worth a one-line note in the PR description so a future cleanup doesn't accidentally remove the old secret.