feat: publish pi-only build into the pi-devbox repo, not opencode-devbox (Option B)

The pi-only variant was published as opencode-devbox:latest-pi-only —
an 'opencode-devbox' tag containing no opencode, which confused users.

- build-variant-pi-only now pushes joakimp/pi-devbox:base-pi-only[-vX.Y.Z]
  instead of opencode-devbox:*-pi-only. New PI_IMAGE workflow env.
- Still built from the same Dockerfile.variant (single source of truth),
  still smoke-tested by smoke-pi-only / validate-pi-only before publish.
- De-advertised pi-only from README, DOCKER_HUB (HUB_TEMPLATE), AGENTS,
  .gitea/README. opencode-devbox now publishes 8 tags + base-latest.
- Documented in CHANGELOG (Unreleased) and the plan doc.

Note: old opencode-devbox:{latest,vX.Y.Z}-pi-only tags from v1.15.13b are
superseded and should be deleted from Docker Hub.

.gitea/README.md

@@ -13,7 +13,7 @@ the build pipeline is shaped the way it is, you're in the right place.
 
 ## Why the split-base pipeline exists
 
-opencode-devbox publishes **five image variants** (`base`, `omos`, `with-pi`, `omos-with-pi`, `pi-only`) × **two architectures** (amd64, arm64) = **ten image tags per release**. Today's runners are 2 self-hosted gitea Actions runners. arm64 builds are emulated under QEMU, which is the dominant cost (~3–5x slower than native).
+opencode-devbox builds **five image variants** (`base`, `omos`, `with-pi`, `omos-with-pi`, `pi-only`) × **two architectures** (amd64, arm64). Four opencode-bearing variants publish under this repo (**eight tags per release** + the floating `base-latest`); the `pi-only` build is pushed into the separate `joakimp/pi-devbox` repo as `base-pi-only` (so no opencode-less tag appears here). Today's runners are 2 self-hosted gitea Actions runners. arm64 builds are emulated under QEMU, which is the dominant cost (~3–5x slower than native).
 
 The five variants share ~95% of their layers (Debian + apt + Node + AWS CLI + mempalace + dev tools + entrypoints). The original `Dockerfile` was a single multi-stage build with `INSTALL_*` build-args gating variant-specific RUNs. BuildKit's per-layer cache key is content-addressed, but as soon as a build-arg-gated `RUN` produces a different layer hash for variant A vs variant B, every subsequent layer also has a different parent → identical commands re-execute per variant. Result: minimal cross-variant cache reuse on a fresh build.
 

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

@@ -37,6 +37,11 @@ concurrency:
 env:
   BUILDKIT_PROGRESS: plain
   IMAGE: ${{ vars.DOCKERHUB_USERNAME }}/opencode-devbox
+  # The pi-only variant is built here (single source of truth for the pi stack)
+  # but published into the pi-devbox repo as an internal building-block tag,
+  # NOT under opencode-devbox — so opencode-devbox never shows a tag with no
+  # opencode in it. pi-devbox's own CI FROMs PI_IMAGE:base-pi-only.
+  PI_IMAGE: ${{ vars.DOCKERHUB_USERNAME }}/pi-devbox
   RELEASE_TAG: ${{ github.ref_type == 'tag' && github.ref_name || inputs.release_tag }}
   PROMOTE_LATEST: ${{ github.ref_type == 'tag' && 'true' || inputs.promote_latest }}
 
@@ -801,11 +806,14 @@ jobs:
       - name: Compute version-specific tags
         id: tags
         run: |
+          # Option B: push the pi-only build into the pi-devbox repo as an
+          # internal building-block tag (base-pi-only[-<version>]), NOT under
+          # opencode-devbox. pi-devbox's CI FROMs ${PI_IMAGE}:base-pi-only.
           VERSION="${{ env.RELEASE_TAG }}"
           { echo "tags<<EOF"
-            echo "${IMAGE}:${VERSION}-pi-only"
+            echo "${PI_IMAGE}:base-pi-only-${VERSION}"
             if [ "${{ env.PROMOTE_LATEST }}" = "true" ]; then
-              echo "${IMAGE}:latest-pi-only"
+              echo "${PI_IMAGE}:base-pi-only"
             fi
             echo "EOF"
           } >> "$GITHUB_OUTPUT"