Pin wrangler to the version that actually runs on the pinned node image

Round 3 (07af755) cleared the artifact path and left one failure:

    check / check                        success   8s
    Build and Deploy .../ build          success   8s   <- green
    Build and Deploy .../ deploy         skipped        <- if: guard
    probe / r1-wrangler-only             failure   7s
    probe / r2a-upload-proven            success  12s
    probe / r2b-download-proven          success   2s
    probe / r3a-upload-node20            success   8s
    probe / r3b-download-node20          success   2s

r2a/r2b and r3a/r3b upload and download the real site tarball across the two
job containers, so the artifact round trip is sound. r1 does nothing but
install wrangler and invoke it, and it fails.

Reproduced locally in the pinned node image, which is faster than another CI
round:

    $ docker run --rm node@sha256:8f693eaa... sh -c \
        'npm install -g wrangler@4.120.0; wrangler --version'
    install exit=0            (with EBADENGINE warnings)
    Wrangler requires at least Node.js v22.0.0. You are using v20.20.2.
    version exit=1

npm treats engines as a warning on an explicit version, so the install step
would have passed and the deploy step would have failed -- a second break,
independent of the artifact one, in the same job nobody could run.

The instructive part is what the unpinned command it replaced was doing:

    $ docker run --rm node@sha256:8f693eaa... sh -c \
        'npm install -g wrangler; wrangler --version'
    `-- wrangler@4.86.0
    4.86.0

npm resolves a bare name to the newest version whose engines the running node
satisfies, so `npm install -g wrangler` on node 20 has been installing 4.86.0,
not the 4.120.0 that `latest` points at. Pinning 4.120.0 was therefore not
"pin the version we are already getting", it was an unnoticed major-ish bump
onto a node the container does not have.

So this pins wrangler 4.86.0 (engines: node >= 20.3.0, published 2026-04-28),
which is exactly the version that has been deploying this site, verified to
install and run on the pinned node 20 digest. The node image digest is left
alone. Bumping the container to node 22 to keep 4.120.0 is the alternative,
but that changes the deploy runtime for no benefit this issue asks for.

Round 4 replaces the probe jobs with a single end-to-end rehearsal: the build
job as written, then the deploy job as written with `wrangler pages deploy
--help` in place of the publish call.

.gitea/workflows/deploy.yml

@@ -95,9 +95,19 @@ jobs:
             - name: Extract site
               run: tar -xzf site.tar.gz
 
+            # 4.86.0, not the 4.120.0 that `latest` points at: wrangler
+            # 4.120.0 requires node >= 22 and refuses to start on this
+            # container's node 20. Note that the unpinned `npm install -g
+            # wrangler` this replaces was never installing `latest` either --
+            # npm picks the newest version whose engines the running node
+            # satisfies, which on node 20 is exactly 4.86.0. So this pins the
+            # version that has actually been deploying this site, rather than
+            # silently changing it. Bumping the container to node 22 is the
+            # alternative; it is a bigger change and is not what this issue is
+            # for.
             - name: Install Wrangler
-              # wrangler 4.120.0, 2026-08-09
-              run: npm install -g wrangler@4.120.0
+              # wrangler 4.86.0, 2026-08-09
+              run: npm install -g wrangler@4.86.0
 
             - name: Deploy to Cloudflare Pages
               run: wrangler pages deploy public --project-name=lora-vegas --branch=${{ github.ref_name }}