Release-train workflows: source the runner PAT, don’t expect a secret

Root cause category: CI/CD — wrong token source for self-hosted kraken-runner jobs Module: repo plumbing (CI)

What happened

The release-train workflows (release-pr-update, pr-risk-classify, release-notes, hotfix-cherrypick, Release Version) were authored with secrets.KRILL_KRAKEN_BOT_PAT. That secret does not exist — the self-hosted kraken/blue/ghost runners get krill-kraken-bot’s PAT from /etc/environment, the same way Nightly Bug Hunt / Dev Agent Blue / Nightly UX Audit do. The empty secret expression resolved to an empty string and shadowed the inherited GH_TOKEN, so gh failed and the integration-PR regeneration silently did nothing. (Caught on the krill-oss canary, mirrored here.)

Fix

• Removed every secrets.KRILL_KRAKEN_BOT_PAT reference.
• Each gh/git push step now does set -a; source /etc/environment 2>/dev/null || true; set +a so the runner’s GH_TOKEN (bot PAT) reaches gh and uv run python subprocesses.
• Release Version (version bump on agents) and hotfix-cherrypick moved to the kraken runner and point origin at a token https remote, so their pushes trigger CI (a default GITHUB_TOKEN push would not, stalling automerge).

Prevention

• Self-hosted-runner jobs authenticate gh/git from /etc/environment (krill-kraken-bot PAT), never from an Actions secret. Copy the Nightly Bug Hunt idiom; don’t invent a secret name.
• env: GH_TOKEN: $ is worse than omitting it — it overrides the inherited value with empty. Omit, or source the real one.
• A PAT (not GITHUB_TOKEN) is required wherever a push must trigger downstream workflows (CI on a bot-opened PR; the assigned event for Blue).