Open the version bump as a pull request

The bump job has never once worked. Its first step died in two seconds on
`set: Illegal option -o pipefail` -- it is the only job here that runs in a
container, and a container job is handed `sh -e {0}` rather than the bash the
runner gives its own jobs. Dash has no `pipefail`, and no `10#` either, so the
arithmetic on the line after would have gone the same way. It now asks for
bash, which node:22 carries.

That would have got the job as far as its last step, which pushed straight to
main. Nothing had ever exercised that, and it needs the token to be allowed
past whatever protects the branch -- hence the second token, VERSION_BUMP_TOKEN,
standing by for where it is not. unsupervised-scheduler has been bumping its
version on every release for a while by pushing a branch and opening a pull
request with the ordinary task token, so that is what this does now. The second
token is no longer needed, and neither is `[skip ci]`: main is never pushed, so
there is no build of the just-published image to suppress. The pull request
puts the changed package.json through a build before it lands.

scheduler builds the request body with jq because its CI image carries jq. This
one is node:22, where node is the thing that certainly is there.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XBT25ZDzm453A8XViSRqRB

CLAUDE.md

@@ -210,16 +210,22 @@ The registry comes from the `REGISTRY` repository variable, the image name from
 `IMAGE_NAME` or the repository name, and credentials from `REGISTRY_USER` and the
 `REGISTRY_TOKEN` secret. Nothing about any particular deployment is committed here.
 
-A release also moves `package.json` on to the next patch version, committed to main by
-the `bump` job — so the number in the tree is never one that has already shipped and
-been made immutable. It lives in `publish.yml` rather than a workflow of its own so it
-can say `needs: build`: a version that failed to publish has not been released, and
-bumping past it would claim otherwise. Prereleases are skipped, being candidates for a
-version that has not shipped. The bump goes through `npm version` rather than an edit in
-place, because the version is in the lockfile too, in more than one place, and the two
-have to agree. The commit carries `[skip ci]`, or pushing it would rebuild the image
-that was just published. Pushing to main needs a token with write access —
-`VERSION_BUMP_TOKEN` overrides the task token where that one cannot.
+A release also moves `package.json` on to the next patch version, opened as a pull
+request by the `bump` job — so the number in the tree is never one that has already
+shipped and been made immutable. It lives in `publish.yml` rather than a workflow of its
+own so it can say `needs: build`: a version that failed to publish has not been
+released, and bumping past it would claim otherwise. Prereleases are skipped, being
+candidates for a version that has not shipped. The bump goes through `npm version`
+rather than an edit in place, because the version is in the lockfile too, in more than
+one place, and the two have to agree.
+
+It arrives as a pull request rather than as a commit straight to main: pushing a branch
+asks nothing of the task token beyond ordinary write access, so it does not matter what
+protects main, and the changed `package.json` goes through a build before it lands.
+Nothing pushes to main, so no `[skip ci]` is needed to stop the bump rebuilding the
+image just published. The job is the only one that runs in a container (`node:22`, for
+npm), and a job in a container is handed `sh`, not bash — hence the explicit
+`shell: bash`, without which `set -o pipefail` fails the first line of the first step.
 
 Two things any deployment has to get right, both learned the hard way: