feat(2036): add-to-kanban authenticates as the App

[LukasWodka]

Refs backend#2036 — the last board writer to move off PROJECTS_KANBAN_TOKEN.

add-to-kanban.yml is a per-repo copy, not a reusable, so this is one PR per repo. The content is byte-identical across every repo that carries it, and the guard compares it that way.

The change

Mint a tracebloc-release-train installation token and use it instead of the PAT.

owner: makes the token org-scoped — a repo-scoped one cannot write the org project at all.

No fallback to the PAT, consistent with the rest of this migration: a fallback would let a broken App path keep working silently, which is the failure class backend#1680 exists to remove.

Dependabot

This workflow also fires on Dependabot PRs, and GitHub gates those on a separate secret scope. Both app secrets are set in the Dependabot scope as well as Actions — without that, Dependabot PRs would stop reaching the board with Input required and not supplied: github-token. That is the exact failure PROJECTS_KANBAN_TOKEN already had to be dual-scoped to avoid.

Ordering

caller-drift compares each repo's copy against .github's as the source of truth, so a fleet-wide change to a copy has an unavoidable drift window. Every other repo merges before .github, which keeps the window on develop rather than on main. .github is the last PR in the sweep.

---

Note

Medium Risk
Changes how automation authenticates to the org project board; misconfigured App secrets or Dependabot-scoped secrets would stop issues/PRs (including Dependabot) from being added to the kanban until fixed.

Overview
Completes the backend#2036 migration for this repo’s add-to-kanban workflow: it no longer uses PROJECTS_KANBAN_TOKEN and instead mints a tracebloc-release-train GitHub App installation token before calling actions/add-to-project.

The mint step uses owner: so the token is org-scoped, which is required to write the org kanban project; there is no PAT fallback, so a broken App path fails visibly instead of silently using the old token.

Inline comments document that Dependabot-triggered runs need the same App secrets in the Dependabot secret scope, or those PRs would fail with missing github-token input.

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

[saadqbal]

Verified against the fleet — cli's post-image is byte-identical to backend#2116, claude-skills#29, frontend-app#826 and start-training#61 (same blob, 07283e3). release-train#86 differs only in its pre-existing on: block, which is expected. Both pins resolve to the right upstream tags (bcd2ba49 = create-github-app-token v3.2.0, 5afcf98f = add-to-project v2.0.0), RELEASE_TRAIN_APP_ID / RELEASE_TRAIN_APP_PRIVATE_KEY are both present in the org Actions secrets visible to this repo, and owner: is there so the token is org-scoped.

Security side is clean: trigger is pull_request, not pull_request_target, so no write-scoped secrets reach fork PRs, and there's no checkout, no run: block and no PR-controlled interpolation anywhere — nothing for a malicious branch name or title to land in. client's live post-merge run also shows Post Mint an installation token -> success, so the token is being revoked. No fallback and no continue-on-error, so a broken App path goes red rather than quietly no-opping.

One non-diff nit, not for this PR: there's still no permissions: block, and no step uses GITHUB_TOKEN any more, so permissions: {} would be tighter — but that's pre-existing and the byte-identical guard means it should move fleet-wide via .github, not here.