ci: the dependabot lockfile fix leaves the PR red, so the queued merge never fires

[ivndev001]

Steps to reproduce

1. Let Dependabot open a PR bumping something in frontend/package.json.
2. bun install --frozen-lockfile fails, because Dependabot does not maintain frontend/bun.lock.
3. .github/workflows/dependabot-lockfile.yml regenerates the lockfile and pushes it to the PR branch.
4. Look at the PR's checks.

Expected

The lockfile commit re-triggers CI, the checks go green, and the PR becomes mergeable with no human involved. That is the point of the workflow.

Actual

The checks stay red until a human re-runs them. The workflow documents this itself:

# KNOWN LIMITATION:
#   The push uses GITHUB_TOKEN, and GitHub does not start new workflow runs for
#   its commits, so the red checks stay red until someone re-runs them. That is
#   still the whole manual clone/install/commit/push removed. To also re-trigger
#   CI unattended, push with a PAT stored as a Dependabot secret (those ARE
#   exposed to `pull_request` runs) in place of GITHUB_TOKEN.

So the lane that exists to make dependency updates unattended still ends with a standing manual step, and it is the last one — everything before it is automated. .maintainer.yml records the outcome plainly: every Dependabot PR so far was merged by hand.

This also strands the sibling lane. .github/workflows/dependabot-automerge.yml arms GitHub's queued-merge feature for non-major updates, and that feature waits on green checks. Checks that stay red until a human re-runs them mean the queued merge never fires on exactly the PRs that needed the lockfile regenerated.

Version

origin/main at 8f7232d.

Suggested fix

The workflow names its own remedy: push with a PAT stored as a Dependabot secret (those are exposed to pull_request runs, unlike repository secrets) instead of GITHUB_TOKEN.

Whoever picks this up should weigh the trade rather than apply it blindly — it swaps a scoped, automatically-rotated token for a long-lived credential on a workflow that runs against Dependabot branches. The existing permissions: block and the if: gate restricting the write step to Dependabot's own same-repo branches are what currently contain that surface; both need to still hold afterwards.

An alternative worth pricing in the same pass: have the workflow re-request the existing check runs through the API after pushing, rather than relying on the push event to start them.

Notes

There is a second interaction worth checking while in here. The main-protection ruleset carries require_extra_approval_for_unattributed_changes: true, and this workflow deliberately commits as github-actions[bot] rather than as the PR author. Whether that combination demands an approval on Dependabot PRs is unverified — if it does, it is a second, independent reason these PRs stop for a human.