CI for checking if tarballs are 'ok-to-deploy' (and enforce bot to check it passes)

We should introduce a CI that checks if tarballs are 'ok-to-deploy', and then have the bot check that CI's status so that it can refuse deployment if the CI doesn't pass.

Main use case that triggered us to think about this is if we make changes to bot/build.sh to run from a software-layer-scripts feature branch:

# bot/build.sh
- git clone https://github.com/EESSI/software-layer-scripts
+ git clone --single-branch --branch CUDA_cuDNN_hooks_202506 https://github.com/casparvl/software-layer-scripts

The ability to do this is nice, since it saves us the hassle of first introducing a dummy EasyStack file in software-layer-scripts (that we then have to remember to remove before merging...) and since fixes introduced/tested in software-layer-scripts now require rebuilds in software-layer after the corresponding software-layer-scripts PR is merged. That can be expensive, and unnecessary, and @bedroge also occasionally found that he had new (random) build failures, which delayed the deployment unnecessarily.

However, the risk of this approach is that stuff gets deployed before that feature branch is merged.

The CI should check the following to make sure deployment if the tarball is ok:

  1. Deploy was triggered with an unaltered bot/build.sh file (i.e. in which case the default branch from https://github.com/EESSI/software-layer-scripts was used)

or

  1. Deploy was triggered with an altered bot/build.sh, pointing to a feature branch at a certain commit and that commit got merged into https://github.com/casparvl/software-layer-scripts

One challenge: I'm not too sure how to check from the context of a CI what the commit was at the time of the build. It's tricky, since it also depends on when the bot actually started to do its build (the build job may have been queued for an X amount of time). The real information would be in the tarball itself, as the build log probably shows the (short) commit hash that was cloned. Something that is close to the truth would be taking the time at which the bot:build command was issued, and checking the git log of the feature branch to see what was the latest commit at that time - and just assume that no commit was done in between issuing the bot:build and the build job actually cloning the software-layer-scripts repo. While not perfect, it is much better than nothing...

Probably, the easiest way to check if this got merged is to checkout the current default branch, and seeing if that git commit is in the history (other stuff may have been added later, but that's normal - at least we know this PR got merged).