fix: harden release-guard workflow and prevent race condition

[bryanbeverly]

Summary

• The release-guard.yml workflow's unset-latest job fails because the gh CLI cannot infer the repository — there is no actions/checkout step and no GH_REPO env var, so gh falls back to looking for a local .git directory which doesn't exist.
• This adds GH_REPO: ${{ github.repository }} to the step's environment so gh knows which repo to target without needing a checkout.
• In release.yml, the "Mark release as latest" step now passes github.ref_name through an env var instead of interpolating it directly into the shell command.
• The guard now checks the Release workflow run status before acting: if the pipeline already succeeded for this tag, the guard skips — preventing a race where a delayed guard run could revert a legitimate release. If the pipeline failed or never ran (manual release), the guard proceeds normally.
• Adds actions: read permission so the guard can query workflow run status.
• Event context (release.tag_name) is also passed through an env var for consistency.

Failed run: https://github.com/trufflesecurity/trufflehog/actions/runs/22491672284

Test plan

• Verify both workflow files are valid YAML
• Create a test release to confirm the workflows pass with the fixes

---

Note

Low Risk
Workflow-only changes; main risk is mis-detecting the release run status or tag and skipping/restoring latest incorrectly.

Overview
Prevents the release-guard.yml workflow from erroneously unsetting latest by first checking whether the release.yml workflow already succeeded for the tag and skipping the guard in that case.

Fixes gh CLI targeting and quoting by adding actions: read permission, setting GH_REPO/RELEASE_TAG env vars (no checkout needed), and updating release.yml to pass the tag via TAG env var when running gh release edit.

^{Written by Cursor Bugbot for commit 0452247. This will update automatically on new commits. Configure here.}

[sysread]

I'm not sure I understand why we've got two separate vars here. Can't we just use RELEASE_TAG throughout the code in this run? If I'm reading it correctly, this is just an alias, which is confusing since it's inconsistent with the env. Or am I misunderstanding something?

[bryanbeverly]

Good catch, this was vestigial and there's nothing gained from it. Removed.