[mrcrgl]

The regeneration pull request asks for a new service's package, or a generator extension, to be added on its branch. The next daily run then threw that work away: it rebuilt the branch from main and force-pushed it. When the API had nothing new, it closed the pull request and deleted the branch.

Now:

• Added commits are found. That means commits on the open pull request's branch that the workflow didn't author or commit, so an amend or rebase counts too. When there are any, a run checks that branch out, merges main into it and generates on top.
• Merge conflicts. Conflicts from that merge in files scripts/update.sh rewrites anyway are resolved automatically. Any other conflict fails the run with a message to merge main by hand.
• Pushing. It pushes with --force-with-lease against the branch as it found it, so a commit pushed during the run fails the run instead of being lost.
• Closing. It deletes the branch, which closes the pull request, only when nobody has added commits, and only as it found the branch. A branch pushed to during the run stays.
• Unreadable origin. If origin's branches can't be read, the run fails instead of treating the branch as absent.
• Forks. A fork's pull request from a branch named regenerate is no longer taken for the workflow's.

Tested:

• shellcheck on both scripts.
• A local simulation of both steps against a bare repository, covering six cases:
  • a commit added by someone else, with main conflicting in generated files;
  • an amended workflow commit;
  • nothing new;
  • a push during the run;
  • a conflict outside generated files;
  • an unreadable origin.
• A dispatch of the first version of this workflow against the open regeneration pull request. It kept the branch and reported it current.