chore(ci): bump create-github-app-token to @v3 (Node 24)

[lucas-d-ramos]

The last Node 20 pin in this repo: actions/create-github-app-token@v1 → @v3 in dependabot-auto-merge.yml.

This is the highest-leverage single line in the sweep — 16 repos call this reusable at @v14, so every one of them currently carries the Node 20 deprecation annotation from this one step.

Everything else here is already Node 24

I inventoried every uses: on main:

ci.yml               checkout@v7, raven-actions/actionlint@v2
dependabot-auto-merge.yml  fetch-metadata@v3, create-github-app-token@v1   <- only stale pin
docker-build.yml     checkout@v7, download-artifact@v8, delete-artifact@v6,
                     metadata-action@v6, setup-buildx-action@v4,
                     login-action@v4.6.0, build-push-action@v7
notify.yml           slackapi/slack-github-action@v4
python-build.yml     checkout@v7, astral-sh/setup-uv@v8.3.2
docker-smoke         using: composite (pure shell, no nested actions)

One exception is not fixable and is left alone: Hardsix/action-wait-for-api@v2.0.2 in deploy-strapi.yml is Node 20, and v2.0.2 is the latest upstream release — there is no version to bump to. That needs its own decision (fork, or replace with a ~10-line curl poll).

Why v1 → v3 is safe

I diffed action.yml at both refs:

• Outputs identical: token, installation-id, app-slug. This workflow consumes steps.app-token.outputs.token.
• All inputs we pass are still accepted; private-key moved from required: false to required: true, and we always pass it.
• The only real removal is v1's deprecated underscore aliases (app_id, private_key). This call site uses the hyphenated form:

uses: actions/create-github-app-token@v3
with:
  app-id: ${{ secrets.app-id }}
  private-key: ${{ secrets.app-private-key }}

Verification is weak here — read before merging

This repo's ci gate is actionlint only. It lints YAML; it does not execute the reusable. A broken token step would lint clean and then silently stop auto-merge across all 16 consumers.

So merging this PR is not the risky step — moving the v14 floating tag is, because that is what consumers actually resolve. I have deliberately not moved it. Per RELEASING.md that is a separate action, and it should follow one deliberate test of auto-merge on a real Dependabot PR in a single tier-2 repo.

For reference, main is currently 1 commit ahead of v14, and that commit touches only .github/dependabot.yml — this repo's own Dependabot config, not any published reusable. So moving the tag would ship this token bump and nothing else functional.

Part of the org-wide Node 24 action sweep.