ci(kanban): run add-to-project on Node 24 (v1.0.2 -> v2.0.0)

[LukasWodka]

What this changes

One line in .github/workflows/add-to-kanban.yml:

- - uses: actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e # v1.0.2+ - uses: actions/add-to-project@5afcf98fcd03f1c2f92c3c83f58ae24323cc57fd # v2.0.0

Nothing else. Part of a 17-repo sweep for tracebloc/backend#1816.

Why

v1.0.2 declares using: node20 in its action.yml. Node 20 is deprecated on
GitHub-hosted runners, so every run today prints the deprecation notice and GitHub
force-runs the action on Node 24 anyway. That forced fallback is explicitly
temporary. When it is withdrawn, all 17 repos still pinned to v1.0.2 break at the
same moment — one action, one pin, seventeen repos. v2.0.0 declares
using: node24, so it needs no fallback.

This is planned maintenance, not an outage fix

Being precise, because the report that started this looked worse than it was:

• The trigger was a single add-to-kanban failure on a backend PR. Re-running the
  exact same job, unchanged, on the unchanged v1.0.2 pin succeeded. The failure
  was a transient TLS condition on that runner, not a runtime incompatibility.
• Across the last 30 add-to-kanban runs in all 19 repos: 542 successes vs 2
  failures (the second being an unrelated one from April). The Node 20 is being deprecated … running with Node 24 line appears on the 542 successes too — it
  correlates with nothing.
• So: nothing is broken right now. This closes a scheduled time-bomb before it goes
  off, and that is the whole claim being made.

Why v2.0.0 specifically, and why it is safe

• Input-compatible.v2.0.0's action.yml declares project-url,
  github-token, labeled, label-operator. This caller passes only
  project-url and github-token. Checked against the action's own action.yml
  at the pinned SHA, not assumed.
• Already proven in our own fleet.cli and release-train have been on this
  exact v2.0.0 pin for a while: 12/12 recent runs successful. They are not
  being changed by this sweep — the other 17 are catching up to them.
• SHA verified, not copied on trust.gh api repos/actions/add-to-project/git/ref/tags/v2.0.0
  returns 5afcf98fcd03f1c2f92c3c83f58ae24323cc57fd.

Blast radius if it did go wrong

add-to-kanban only adds new issues/PRs to the board. kanban-reconcile.yml
(Mondays 04:00 UTC) adds anything add-to-kanban missed, so a miss self-heals
within a week and nothing accumulates silently.

Verification run on this repo

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/add-to-kanban.yml'))" — parses.
• actionlint .github/workflows/add-to-kanban.yml — clean (actionlint 1.7.12, the
  version tracebloc/.github pins in CI). This repo has no workflow-lint job of its own, so actionlint was run locally rather than in CI; the quality / action-pins gate (SHA-pin grammar) is satisfied — the new ref is a full 40-hex commit SHA.
• git diff --stat — 1 file changed, 1 insertion(+), 1 deletion(-). No reformatting.
• The resulting file is byte-identical to the canonical copy in tracebloc/.github
  (git blob 603751a070de), which is what caller-drift.py compares copies on.

This PR tested itself

For pull_request events GitHub reads the workflow file from the PR's head, so
this PR's own add-to-kanban run executed the new pin, before any merge:

Download action repository 'actions/add-to-project@5afcf98fcd03f1c2f92c3c83f58ae24323cc57fd'
Run actions/add-to-project@5afcf98fcd03f1c2f92c3c83f58ae24323cc57fd
with: project-url: https://github.com/orgs/tracebloc/projects/2
github-token: ***
Creating project item

17/17 of this sweep's PRs added their card successfully on the v2.0.0 pin, and the
Node 20 is being deprecated line is absent from those logs — which is the point of
the change.

Review

Reviewer intentionally not requested yet — see tracebloc/backend#1816; this is
queued behind the current review batch. 17 simultaneous review requests would bury
the team, so the batch gets sequenced by hand.

Refs tracebloc/backend#1816