ci: harden dependabot-tidy workflow to allow auto-triggering CI

[BjoernKarma]

What changed and why

pull_request → pull_request_target

The old event fired in the PR's fork/bot context with a read-only token, requiring maintainer approval. pull_request_target always runs in the base branch context with a write-capable GITHUB_TOKEN no maintainer authorization needed.

Security safeguard added: we check out the PR by its immutable SHA (pr.head.sha), not the branch name. This prevents a malicious PR from being substituted mid-run. The job is also guarded by github.actor == 'dependabot[bot]'.

GitHub App token for re-triggering CI

A commit pushed with GITHUB_TOKEN is explicitly blocked from re-triggering workflows by GitHub (anti-recursion). A GitHub App token bypasses this restriction. The new step conditionally generates one using actions/create-github-app-token when APP_ID and APP_PRIVATE_KEY secrets exist. Falls back gracefully to GITHUB_TOKEN (push works, but CI won't auto-rerun).

Explicit push target

Checking out by SHA puts git in detached HEAD state. The old git push would fail. Now it uses git push origin HEAD:"$HEAD_REF" with the branch name surfaced from the PR metadata.

workflow_dispatch now accepts pr_number So a maintainer can manually run tidy on any PR without needing to edit the workflow

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[stefan-ctrl]

LGTM. Has harding to prevent go mod tidy jobs overwrite other stuff and generally prevent escalation.

Should try it out, if this solves some issues. 👍