[BUGFIX] Enqueue Dependabot PRs with an App token

[linawolf]

Since the merge queue on "main" was introduced (#1326), no Dependabot
pull request has been merged automatically. The Auto-merge workflow
still reports success, and the pull request is enqueued — but the merge
group is then dropped again about 30 minutes later, and every bump has
had to be merged by hand since 2026-07-18.

Events created with the GITHUB_TOKEN do not trigger workflow runs. The
merge group created by enqueuing with it therefore never runs the "Main"
workflow, its required status checks stay pending, and the queue evicts
the entry once check_response_timeout_minutes elapses.

The run history shows the split cleanly: every merge_group run since the
queue was introduced belongs to a merge enqueued by a person, and every
merge group created by github-actions[bot] has no run at all.

Mint a token from the GitHub App instead, whose events are not subject to
that restriction. APP_ID and APP_PRIVATE_KEY are already available to
this repository as organization secrets.

Also drop --squash: the merge method comes from the merge queue rule on
"main", and gh warns that the flag is ignored.

[linawolf]

A concrete reproduction from this afternoon, in case it helps the review — the
failure this PR describes happened live on #1389 while I was clearing the
Dependabot backlog.

Control: four PRs merged by hand. I merged #1367, #1384, #1383 and #1385
manually between 18:54 and 18:58 UTC. Each produced a merge_group run of
"Main" that completed successfully:

18:52:45  merge_group  Main  success  .../actions/runs/34517015393
18:55:10  merge_group  Main  success  .../actions/runs/34517258396
18:55:12  merge_group  Main  success  .../actions/runs/34517261159
18:55:35  merge_group  Main  success  .../actions/runs/34517301878

Then the bug. Dependabot rebased #1389 onto the new main, which fired
pr-auto-merge on the resulting synchronize event:

18:59:41  pull_request_target  success  .../actions/runs/34517705938   <- enqueued with GITHUB_TOKEN
19:01:11  merge queue entry created — position 1, AWAITING_CHECKS

There is no merge_group run after 18:55:35. The merge group created by that
GITHUB_TOKEN enqueue never triggered "Main", exactly as the comment in this PR
predicts. The entry sat at position 1 in AWAITING_CHECKS for around thirty
minutes until I dequeued it by hand; left alone it would have run out
check_response_timeout and been dropped.

And the counter-test. When I later pushed a commit to that same branch
myself, pr-auto-merge ran again and skipped, because github.actor was no
longer dependabot[bot]:

19:30:35  pull_request_target  skipped   .../actions/runs/34520811489

Same PR, same branch, same workflow — the only variable is who created the
enqueue event.

Two things this adds beyond the current description:

• A stuck entry sits at position 1 and holds the queue. Anything queued
  behind it waits on it, so the blast radius isn't limited to the Dependabot PR
  that triggered it.
• It re-arms itself. Dependabot rebases whenever main moves, each rebase
  is a synchronize, and each synchronize enqueues again — so the PR returns
  to the broken state on its own after every merge to main. That's why these
  bumps look "approved and green" indefinitely rather than failing visibly.

Also, a correction to something I wrote on #1265: I described five Dependabot
PRs as stuck on this. It is three. #1367 (jsdom 29 to 30) and #1384 (jest-dom 6
to 7) are majors, which the semver-patch || semver-minor guard declines by
design — those were waiting on a human, not on this bug. The mechanism above is
unaffected.