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

[LukasWodka]

What this changes

Three things, all one topic — this repo's own add-to-kanban caller, and the
inventory that declares what the fleet's caller is supposed to be. Part of the
17-repo sweep for tracebloc/backend#1816.

1. This repo's caller (.github/workflows/add-to-kanban.yml), same one-line bump
as the other 16:

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

2. repo-inventory.yml — v2.0.0 becomes the norm, not the drift.

• cli's add-to-kanban.yml entry goes from divergent (with a reason that said
  "cli's copy has drifted: it pins v2.0.0 where every other repo pins v1.0.2") to a
  plain required. Its "drift" is now the standard. The guard proves this rather
  than asserting it: with this PR's canonical copy in place, cli's blob matches
  byte-for-byte (603751a070de), so copies reads OK for cli — and had it
  stayed divergent, the guard would now fail it with "marked divergent but now
  matches tracebloc/.github exactly".
• release-train's entry stays divergent, but its reason was half false and is
  corrected. It read: "adds a header … and pins v2.0.0 rather than v1.0.2. The
  comment is wanted; the version pin is drift." After this PR the pin is not drift,
  so the reason now names the header comment as the only remaining difference. The
  entry has to stay divergent because that header genuinely makes the file differ
  from the canonical copy.
• stale-backlog.yml's separate divergent entries are untouched, and
  devex-bootstrap's exempt (no .github directory at all) is untouched.

3. README.md — the onboarding checklist told a new repo to pin
actions/add-to-project@v1.0.2. Following it after this PR would reintroduce the
node20 pin the sweep just removed, so the example is updated. The
"@v1 does not exist" note stays true and gains the equally true note that a bare
@v2 moves.

grep -rn 244f685 across this repo now returns nothing.

Why the bump

v1.0.2 declares using: node20. Node 20 is deprecated on GitHub-hosted runners, so
GitHub force-runs the action on Node 24 today and prints the deprecation notice on
every run. That fallback is explicitly temporary; when it is withdrawn, every repo
still on v1.0.2 breaks at the same moment. v2.0.0 declares using: node24.

This is planned maintenance, not an outage fix

• The trigger was one add-to-kanban failure on a backend PR. Re-running that exact
  job, unchanged, on the unchanged v1.0.2 pin succeeded — a transient TLS
  condition on the runner, not a runtime incompatibility.
• Fleet-wide over the last 30 runs per repo: 542 successes vs 2 failures (the
  second unrelated, from April). The Node 20 is being deprecated … running with Node 24 line appears on the 542 successes too.
• cli and release-train have run this exact v2.0.0 pin successfully (12/12
  recent runs) — a proven-good config in our own fleet, not a leap.
• Input-compatible, checked against the action's own action.yml at the pinned SHA:
  it declares project-url, github-token, labeled, label-operator; our callers
  pass the first two.
• SHA verified independently: gh api repos/actions/add-to-project/git/ref/tags/v2.0.0
  → 5afcf98fcd03f1c2f92c3c83f58ae24323cc57fd.

Blast radius if a run did fail anyway: kanban-reconcile.yml (Mondays 04:00 UTC) adds
anything add-to-kanban missed, so a miss self-heals within a week.

⚠️ Merge this PR LAST, after the other 16 have landed on develop

This is the guard's own documented awkwardness (caller-drift.py docstring: "the
inventory is read from the checkout, but every repo's state … is read from its audit
branch over the API"). Copies are compared by git blob id against the canonical
file in this checkout. So while the other 16 PRs are still open, this PR's
canonical copy is v2.0.0 and their develop branches are still v1.0.2 — and the
audit correctly reports 16 drifted copies:

::error::16 repo-conformance drift finding(s).
- averaging-service: add-to-kanban.yml has DRIFTED from the copy in tracebloc/.github
(blob 3b6d693535ef vs 603751a070de). It is a copy, not a caller, so nothing else
would ever notice.
… 15 more, identical blob pair: backend, claude-skills, client, client-runtime,
data-ingestors, design-system, docs, e2e-test-agent, frontend-app, model-zoo, rfcs,
start-training, tracebloc-engine, tracebloc-py-package, tracebloc-website
EXIT=1

cliOK, release-trainOK, devex-bootstrapOK, .githubOK
(source of truth, presence only) — i.e. every finding is a repo whose sweep PR has not
merged yet, and every one is the same blob pair. conformance-gate is a required
check here, so this PR stays red until the 16 are on develop. That is the
fail-closed direction and it resolves itself; nothing to override.

The resolution is deterministic, not hopeful: each of the 16 branches produces a file
that hashes to exactly 603751a070de6d5f0b8760240fa5da5ecba55b71, the same blob as
this PR's canonical copy and as cli's file on develop today. Verified with
git hash-object on all 17 edited files — one distinct hash across all of them.

Verification run

• Baseline first — the audit on unmodified develop: EXIT=0, "No drift. Every
  repo read, every entry matched." 20/20 repos, all five families OK. So the 16
  findings above are caused by this batch being mid-flight, not by a pre-existing mess.
• python3 scripts/tests/caller-drift-selftest.py → pass=123 fail=0.
• python3 scripts/caller-drift.py --inventory repo-inventory.yml --source-dir .
  (exactly as caller-drift.yml invokes it) → output above.
• python3 -c "import yaml; yaml.safe_load(open('repo-inventory.yml'))" — parses; 20
  repos; cli → required, release-train → divergent with the corrected reason.
• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/add-to-kanban.yml'))" — parses.
• actionlint over the whole tree, as actionlint.yml runs it, at the version it
  pins (1.7.12) → clean, exit 0.
• Caller diff is exactly 1 insertion, 1 deletion in one file; no reformatting.

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. Note the merge-last ordering above when
sequencing this one.

Refs tracebloc/backend#1816

[LukasWodka]

The red audit / gate here is expected, and is the ordering constraint — not a finding to fix

CI reproduced my local run exactly: 16 findings, all one class, every one
add-to-kanban.yml has DRIFTED … (blob 3b6d693535ef vs 603751a070de). No other finding
type appears, and selftest passed (123/123).

Those 16 are precisely the 16 sibling PRs in this sweep that have not merged yet.
caller-drift.py compares copies by git blob id against the canonical file in this
checkout, while each repo's state is read from its develop over the API — the
awkwardness its own docstring documents. This PR moves the canonical copy to v2.0.0
while their develop branches are still v1.0.2, so the guard is telling the truth.

Resolution: merge this PR last. All 16 branches produce a file hashing to exactly
603751a070de6d5f0b8760240fa5da5ecba55b71 — the same blob as this PR's canonical copy
— so once they are on develop the audit goes green with no further change here. I
will not push anything to make the check pass early, and this does not want
skip-fr-gate or any override.

Baseline for contrast: the same audit on unmodified develop is EXIT=0, "No drift.
Every repo read, every entry matched."

[LukasWodka]

⚠️ MERGE THIS PR LAST — after the other 16

The two red checks (gate, audit) are expected and correct, and cannot be fixed by editing this PR. Please don't try to make them green before the fleet lands.

Why:add-to-kanban.yml is a copies: entry, so caller-drift.py compares each repo's blob sha against this repo's copy as the source of truth (audit_branch: develop-first). This PR bumps the source-of-truth copy to v2.0.0 (blob 603751a070de), so every repo still on v1.0.2 (3b6d693535ef) is now reported as drifted:

##[error]16 repo-conformance drift finding(s).
- backend: add-to-kanban.yml has DRIFTED from the copy in tracebloc/.github (blob 3b6d693535ef vs 603751a070de)
- client: … (×16)

That is the guard working as designed — it is fail-closed, and during a fleet-wide copy bump there is genuinely a window where the copies disagree.

Consequence if this merges first:main would hold v2.0.0 while 16 repos hold v1.0.2, so the scheduled org audit goes red until the last one lands — noisy, and it trains people to ignore a red audit.

Correct order

1. Merge the 16 caller PRs (all individually green — they don't run this audit): backend#1817, client#684, client-runtime#316, tracebloc-engine#627, data-ingestors#491, averaging-service#336, e2e-test-agent#78, frontend-app#790, design-system#142, tracebloc-py-package#415, model-zoo#150, docs#110, start-training#58, tracebloc-website#490, rfcs#22, claude-skills#26.
2. Then re-run this PR's checks. With all 16 copies matching, the audit goes clean and the gate passes.
3. Merge this one.

This PR carries the parts that declare the new norm, which is why it belongs last: the repo-inventory.yml flip making v2.0.0 required (and deleting cli's now-obsolete divergent note), plus the README.md line that told new repos to pin v1.0.2.

Refs backend#1816.