Open one auto-merging PR per package from every sync workflow

sync-upstream.yml, sync-rebuilds.yml and track-branches.yml each opened one
batch PR, so one package with a failing build held back every other update
in it (#788, #837). All three now group their changes with
package-pr-groups.sh and hand them to package-prs.yml, which opens a PR per
package and arms auto-merge. Packages pinned from the same upstream branch
still share one. Green packages land on their own and only the failures stay
open; a red PR conflicting with master, and each lane's old batch PR, get
closed.

sync-upstream.yml loses its human-merged lane: it now pushes with the PAT
like the other two, so its builds start without an approval hold and its PRs
auto-merge when green. min_release_age still quarantines fresh releases. Its
approve job, approve-sync-push.cjs, and auto-merge-pr.cjs's exception for
auto/sync-upstream go with it.

docs/rebuild-triggers.md

@@ -37,7 +37,8 @@ A dependency this repository carries for an architecture (a recipe here that bui
 
 ## The workflow
 
-`sync-rebuilds.yml` runs `bin/sync-rebuilds` every 6 hours, opens one PR on
-`auto/sync-rebuilds` and enables auto-merge. The PR lands once `result`,
-`self-tests` and `build-isolation` pass, and the merge publishes. A rebuild that
-fails stays an open red PR for a maintainer.
+`sync-rebuilds.yml` runs `bin/sync-rebuilds` every 6 hours and opens one PR per
+package on `auto/sync-rebuilds-<package>` with auto-merge enabled. Each PR lands
+once `result`, `self-tests` and `build-isolation` pass, and the merge publishes.
+A rebuild that fails stays an open red PR for a maintainer without holding back
+the others.

docs/upstream-sources.md

@@ -80,8 +80,9 @@ the time a commit was pushed, measured from when the run cloned the branch so
 packages pinned from it agree. `BYPASS_MIN_RELEASE_AGE=1` bypasses the hold.
 
 Packages marked `"auto_merge": true` ride the unattended lane
-(`track-branches.yml`) instead of the reviewed sync PR: their bump PR is opened
-and auto-merged as soon as the build checks pass. Each package gets its own
+(`track-branches.yml`), checked hourly instead of every 6 hours. Every lane
+opens its PRs through `package-prs.yml` and auto-merges them as soon as the
+build checks pass. Each package gets its own
 PR on `auto/track-branches-<package>`, and packages that pin the same branch
 share one, so a package whose build fails holds back only itself. The lane works with every
 provider, not only branch watches, so it also carries release feeds trusted to
@@ -228,22 +229,20 @@ These packages were already excluded from automatic AUR updates. The migration p
 - Spotify uses HTTPS and retains its signed Release/Packages verification.
 - Source and build compatibility still need review when upstream code changes. Direct watches remove AUR recipe churn, not the need to maintain packaging.
 
-## How the sync PR builds
+## How the sync PRs build
 
-`sync-upstream.yml` pushes its PR with the built-in `GITHUB_TOKEN`, so GitHub
-holds the PR's build and test runs for approval. The workflow labels its own
-PR `build-approved`, and its `approve` job releases the held runs for each
-commit it pushes. A push to an `auto/sync-*` branch, or to one of the
-tracker's `auto/track-branches-*` branches, does not cancel the PR's build in flight: the new
+`sync-upstream.yml`, `sync-rebuilds.yml` and `track-branches.yml` each run their
+sync once, split the changed recipes into one PR per package with
+`.github/scripts/package-pr-groups.sh`, and hand them to `package-prs.yml`. That
+pushes each PR with the PAT in `PKGS_BOT_TOKEN`, so its builds start without an
+approval hold, and arms auto-merge. A push to an `auto/sync-*` or
+`auto/track-branches-*` branch does not cancel the PR's build in flight: the new
 build waits, then reuses every artifact the finished one uploaded.
 
-Because of that push, GitHub starts no `pull_request_target` workflow for the
-PR, so `auto-merge-pr.yml` never arms it: a maintainer merges it.
-
-A run started by hand with `packages` opens its own PR on
-`auto/sync-upstream-<packages>`. The next scheduled run still picks the same
-update up in the shared PR if it has not merged by then; identical package
-trees reuse the same build artifacts.
+A red PR stays open for a maintainer and holds back only its own package. A
+later run updates it if upstream moves again, and closes it once it conflicts
+with `master`. A run started by hand with `packages` updates the same
+per-package PRs a scheduled run would.
 
 ## Declarative providers and hooks