CI: harden promote-base-latest (pinned crane + skip on cache-hit)

Two workflow-only changes for promote-base-latest, no image-side impact:

T14 \u2014 replace imjasonh/setup-crane@v0.4 with direct pinned crane install.
The action's bootstrap script calls api.github.com/.../releases/latest
at every run to discover the crane version. That call periodically
rate-limits and returns JSON without .tag_name, jq emits 'null', the
action then downloads .../releases/download/null/... \u2192 404 \u2192 'gzip:
unexpected end of file' \u2192 exit 2. We hit this on the v1.15.3 release
(2026-05-16) where it was cosmetic only \u2014 base-latest was already
correct from cache hit \u2014 but the red-X is annoying.

Replaced with curl + tar pinned to crane v0.21.6 (latest at time of
change). Same pattern as other GitHub-sourced binaries in the
Dockerfile layer (gosu, fzf, eza etc.); operator bumps CRANE_VERSION
deliberately when wanting updates.

T15 \u2014 gate promote-base-latest on need_build == 'true'. When the base
layer's content hash hasn't changed (cache hit on existing base-<hash>
from a prior run), base-latest already points at the correct digest.
The retag is a tautology, and any transient failure of it produces a
red-X for an operation that didn't need to happen. Skipping the job
entirely on cache-hit is correct and removes a whole class of cosmetic
failure. Manual workflow_dispatch with promote_latest=true still bypasses
the gate as an escape hatch (e.g., if base-latest got hand-deleted and
needs regeneration without rebuilding the base).

This will not trigger a CI publish run (main-branch commit, no tag).

.gitea/workflows/docker-publish-split.yml

@@ -526,12 +526,33 @@ jobs:
       - build-variant-omos
       - build-variant-with-pi
       - build-variant-omos-with-pi
-    if: ${{ github.ref_type == 'tag' || inputs.promote_latest == 'true' }}
+    # Skip on cache-hit base builds: when need_build=false, base-latest
+    # already points at the same digest as base-<hash>, so the retag is
+    # a tautology and any transient failure of it is purely cosmetic.
+    # Manual workflow_dispatch with promote_latest=true overrides this
+    # gate as an escape hatch (e.g., if base-latest got hand-deleted).
+    if: |
+      inputs.promote_latest == 'true' ||
+      (github.ref_type == 'tag' && needs.base-decide.outputs.need_build == 'true')
     runs-on: ubuntu-latest
     container:
       image: catthehacker/ubuntu:act-latest
     steps:
-      - uses: imjasonh/setup-crane@v0.4
+      # Direct pinned install instead of imjasonh/setup-crane@v0.4. The
+      # action's bootstrap script calls api.github.com/.../releases/latest
+      # to discover the crane version, which periodically rate-limits and
+      # produces tag=null → download from .../download/null/... → 404 →
+      # 'gzip: unexpected end of file' → exit 2. Pinning removes the
+      # runtime dependency on GitHub API entirely. Bump CRANE_VERSION
+      # deliberately when you want updates.
+      - name: Install crane (pinned)
+        env:
+          CRANE_VERSION: v0.21.6
+        run: |
+          set -eux
+          curl -fsSL "https://github.com/google/go-containerregistry/releases/download/${CRANE_VERSION}/go-containerregistry_Linux_x86_64.tar.gz" \
+            | tar -xz -C /usr/local/bin crane
+          crane version
       - name: Login (crane)
         run: |
           crane auth login docker.io \