Cut v1.15.12 — revert v4.0.0 pin (busted), bump pi to 0.76.0

The v1.15.11b experiment confirmed setup-buildx-action@v4.1.0 is NOT
the regressor: pinning all 9 references to @v4.0.0 reproduced the
exact same '400 Bad request' from registry-1.docker.io on the first
layer-blob PUT. CI run #336 failed twice (original + Gitea auto-rerun),
both with HTML 400 bodies (CDN-tier rejection) at Offset:0. UUIDs and
_state signatures differ across attempts; only the failure pattern is
stable.

Reverting all 9 pins back to @v4 — keeping a wrong pin holds us off
action improvements with no benefit. Real suspects now narrow to:
runner-image (catthehacker:act-latest, floating), runner-2 host
network egress, buildx 0.34.x signed _state token format, or per-repo
Hub-side state. Investigation deferred; this release ships via manual
docker buildx build --push from a developer Orbstack to bypass the
broken runner-network → Hub-CDN combo (we know that path works in
~25s for the same multi-arch build to the same Hub account).

PI_VERSION=latest resolves to pi-coding-agent 0.76.0 (published
2026-05-27 20:03 UTC). OPENCODE_VERSION stays at 1.15.11 (no upstream
bump since 1.15.11 was published 2026-05-27 03:59 UTC).

Files:
- .gitea/workflows/docker-publish-split.yml: 9 setup-buildx-action
  references reverted from @v4.0.0 to @v4
- CHANGELOG.md: v1.15.12 entry with regression triage status
  (ruled-out vs still-suspect)

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

@@ -174,7 +174,7 @@ jobs:
           platforms: arm64
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v4.0.0
+        uses: docker/setup-buildx-action@v4
         with:
           driver-opts: network=host
 
@@ -223,7 +223,7 @@ jobs:
             /usr/lib/jvm 2>/dev/null || true
           docker system prune -af --volumes || true
           docker builder prune -af || true
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -267,7 +267,7 @@ jobs:
             /usr/lib/jvm 2>/dev/null || true
           docker system prune -af --volumes || true
           docker builder prune -af || true
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -312,7 +312,7 @@ jobs:
             /usr/lib/jvm 2>/dev/null || true
           docker system prune -af --volumes || true
           docker builder prune -af || true
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -357,7 +357,7 @@ jobs:
             /usr/lib/jvm 2>/dev/null || true
           docker system prune -af --volumes || true
           docker builder prune -af || true
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -403,7 +403,7 @@ jobs:
           docker builder prune -af || true
       - uses: docker/setup-qemu-action@v3
         with: {platforms: arm64}
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -451,7 +451,7 @@ jobs:
           docker builder prune -af || true
       - uses: docker/setup-qemu-action@v3
         with: {platforms: arm64}
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -500,7 +500,7 @@ jobs:
           docker builder prune -af || true
       - uses: docker/setup-qemu-action@v3
         with: {platforms: arm64}
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:
@@ -549,7 +549,7 @@ jobs:
           docker builder prune -af || true
       - uses: docker/setup-qemu-action@v3
         with: {platforms: arm64}
-      - uses: docker/setup-buildx-action@v4.0.0
+      - uses: docker/setup-buildx-action@v4
         with: {driver-opts: network=host}
       - uses: docker/login-action@v3
         with:

CHANGELOG.md

@@ -8,7 +8,43 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a
 
 ## Unreleased
 
-_(no changes since v1.15.11b)_
+_(no changes since v1.15.12)_
+
+---
+
+## v1.15.12 — 2026-05-28
+
+Manual-published release. Reverts the `setup-buildx-action@v4.0.0` pin from v1.15.11b (hypothesis was disproven — see below) and bumps the bundled `pi-coding-agent` to 0.76.0 via the floating `PI_VERSION=latest` resolution.
+
+### Why "manual-published"
+
+v1.15.11b reproduced the exact same Hub `400 Bad request` regression as v1.15.11 (CI run #336, build-base failed twice including a Gitea auto-rerun), confirming `setup-buildx-action@v4.1.0` is **not** the regressor. After four consecutive identical CI failures across two days, the SSH-CM and gitleaks fixes were shipped by hand from a developer host's Orbstack/Docker-Desktop — a path we already knew worked in ~25s for the same multi-arch build to the same Hub account.
+
+This release ships the same content the runner-side build would have shipped; it just bypasses the broken runner-network → Hub-CDN combo. CI auto-publishing remains broken pending separate runner-side investigation (see [AGENTS.md — known issues](AGENTS.md)).
+
+### Workflow change
+
+- **`.gitea/workflows/docker-publish-split.yml`** — all nine `setup-buildx-action@v4.0.0` pins reverted to `@v4`. The pin added no value (failure reproduced) and was holding us off action improvements.
+
+### Bumped: pi-coding-agent (latest → 0.76.0)
+
+`PI_VERSION=latest` in `Dockerfile.variant` resolves at build time. 0.76.0 was published 2026-05-27 20:03 UTC. No Dockerfile edit needed; floating-`latest` is intentional so each opencode-devbox release pulls the freshest pi without a manual bump.
+
+### Hub-push regression — ruled out / still suspect
+
+**Ruled out:**
+- `setup-buildx-action@v4.1.0` — v4.0.0 reproduces the failure identically.
+- `@docker/actions-toolkit 0.79.0 → 0.90.0` — rolled back via the action pin; same failure.
+- Account / repo / Hub-CDN globally — local pushes from a developer host succeed.
+- Multi-arch as such — pi-devbox v0.75.5b pushed multi-arch on 2026-05-23.
+
+**Still suspect:**
+- `catthehacker/ubuntu:act-latest` runner image (floating, not pinned in workflows).
+- act-runner host network egress from `runner-2` (sustained CDN-edge rejection from this specific source IP).
+- buildx 0.34.x's signed `_state` token format hitting a Hub-edge WAF/length rule that didn't apply to 0.33.x.
+- Hub-side per-repo state for `joakimp/opencode-devbox` specifically (other Hub repos from the same account work).
+
+Four failing runs share the exact failure shape: HTTP 400 with HTML body (CDN-tier, not registry backend) on the very first PUT (`Offset:0`) of the resumable layer-blob upload. UUIDs and `_state` signatures differ across attempts — only the failure pattern is stable.
 
 ---