ci(tests): publish what the job was told to pull, and pin it

DP-007's row says the builder image is "pinned by tag in the Gitea
container registry". The tag was pinned; the image was never pushed.
Every run since the workflow landed died at
"Error response from daemon: manifest unknown" before a single step ran,
so the tier this workflow exists to execute has still never executed.

sae-builder-cpu:v1 is now in the registry, built from ff3b8eb by
scripts/ci/build_builder_image.sh and reporting SAE_BUILDER_VERSION=v1,
which is what the job's own assert-the-image step demands. The
v1-ff3b8eb audit tag went with it.

Behind that, the same absence one layer down: no replay-fixtures package
existed either, so "Verify the fixtures actually arrived" would have
failed next. tests/fixtures/dumps is now published at version ff3b8eb.

Which makes the `latest` here worth removing rather than keeping. Two
reasons, either sufficient. It is the same argument DP-007 already
makes about the image tag -- a dump is an input to the tests, so a
re-upload under a moving `latest` retroactively changes what an earlier
green build proved. And `latest` was the only thing in this job that
wanted a credential: package downloads are anonymous while the repo is
public, and only resolving `latest` needs a token for the list endpoint.
No GITEA_TOKEN secret is configured on this repo, so that step could
never have resolved `latest` even once the image existed. Pinning
deletes the dependency instead of documenting it.

The failure message below it said the step "needs GITEA_TOKEN to resolve
'latest'"; it now says to check the pinned version still exists, which
is the thing that can actually go wrong -- pull_artifacts.sh warns and
continues on a missing version rather than failing, which is why that
verify step is there at all.

TRACES: DP-007 | PR-004

.gitea/workflows/unit-tests.yml

@@ -78,12 +78,22 @@ jobs:
             exit 1
           }
 
+      # Pinned to a version, never `latest`, for the same reason the builder
+      # image above is: a dump is an input to the tests, so a moving `latest`
+      # would let a re-upload retroactively change what an earlier green build
+      # proved. It also removes a credential from this job entirely -- package
+      # DOWNLOADS are anonymous while the repo is public, and only resolving
+      # `latest` needs a token (the list-packages endpoint requires auth on this
+      # instance). `latest` was the sole reason this step wanted GITEA_TOKEN,
+      # and no such secret is configured, so it could never have resolved.
+      #
+      # Bumping the fixtures means uploading a new version with
+      # scripts/artifacts/push_artifacts.sh replay-fixtures and editing the SHA
+      # here, in the same commit -- as with the image tag.
       - name: Fetch replay fixtures
-        env:
-          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
         # bash, not sh: the script declares #!/bin/bash and uses `set -o
         # pipefail` and arrays, which dash does not have.
-        run: bash scripts/artifacts/pull_artifacts.sh replay-fixtures latest
+        run: bash scripts/artifacts/pull_artifacts.sh replay-fixtures ff3b8eb
 
       # pull_artifacts.sh warns and continues when a package version is missing,
       # which is right for a developer pulling one artifact of several and wrong
@@ -107,7 +117,9 @@ jobs:
             echo "Replay fixtures are absent, so the T2 tier cannot run." >&2
             echo "They are not in git (tests/fixtures/dumps/.gitignore) -- they" >&2
             echo "live in the Gitea generic package registry and are pulled by" >&2
-            echo "the step above, which needs GITEA_TOKEN to resolve 'latest'." >&2
+            echo "the step above, at the version pinned there. Check that the" >&2
+            echo "version still exists in the registry: pull_artifacts.sh warns" >&2
+            echo "and continues on a missing one rather than failing." >&2
             exit 1
           fi