build via platform.hanzo.ai, not GitHub Actions

GitHub answers a workflow dispatch on this repo with 422 "Actions has been
disabled for this user", so pushes to main produced no build at all — the last
run is still the commit before the console removal, and the deployed image
drifted behind main without anything reporting a failure.

hanzo.yml hands the build to platform.hanzo.ai, which schedules it onto the
self-hosted arcd pools over the native fabric and pushes to GHCR. Same path
luxfi/node uses. .github/workflows/build-lux-kms.yml is retired rather than
left as a second, broken way to produce the same image.

No deploy block: the kms Deployment is kustomize-managed with no operator CR,
so there is nothing for a Service-CR rollout to target.

VERSION 1.12.6 -> 1.12.8. The file had fallen behind the deployed tag v1.12.7,
so a tag build would have gone backwards.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>

.github/workflows/build-lux-kms.yml

@@ -1,73 +0,0 @@
-name: Build KMS
-
-# Self-contained — calling hanzoai/.github/.github/workflows/docker-build.yml@main
-# via `secrets: inherit` triggers a cross-org startup_failure (organization
-# secrets aren't inherited across orgs even with `inherit`). Same pattern
-# already used by build-server-self.yml.
-
-on:
-  push:
-    branches: [main]
-    tags: ['v*']
-  workflow_dispatch:
-
-permissions:
-  contents: read
-  packages: write
-
-jobs:
-  build:
-    runs-on: lux-build
-    timeout-minutes: 45
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Compute tags
-        id: meta
-        run: |
-          if [[ "$GITHUB_REF" == refs/tags/v* ]]; then
-            VERSION="${GITHUB_REF#refs/tags/v}"
-            {
-              echo "tags<<EOF"
-              echo "ghcr.io/luxfi/kms:v${VERSION}"
-              echo "ghcr.io/luxfi/kms:${VERSION}"
-              echo "ghcr.io/luxfi/kms:sha-${GITHUB_SHA:0:7}"
-              echo "EOF"
-            } >> "$GITHUB_OUTPUT"
-          else
-            {
-              echo "tags<<EOF"
-              echo "ghcr.io/luxfi/kms:sha-${GITHUB_SHA:0:7}"
-              echo "EOF"
-            } >> "$GITHUB_OUTPUT"
-          fi
-
-      - name: Login to GHCR
-        uses: docker/login-action@v3
-        with:
-          registry: ghcr.io
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Set up Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Build and push (linux/amd64, with embedded SPA)
-        uses: docker/build-push-action@v6
-        with:
-          context: .
-          file: Dockerfile
-          platforms: linux/amd64
-          build-args: |
-            GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }}
-          push: true
-          tags: ${{ steps.meta.outputs.tags }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max
-
-      - name: Summary
-        run: |
-          echo "### Build complete" >> "$GITHUB_STEP_SUMMARY"
-          echo '```' >> "$GITHUB_STEP_SUMMARY"
-          echo '${{ steps.meta.outputs.tags }}' >> "$GITHUB_STEP_SUMMARY"
-          echo '```' >> "$GITHUB_STEP_SUMMARY"

VERSION

@@ -1 +1 @@
-1.12.6
+1.12.8

hanzo.yml

@@ -0,0 +1,23 @@
+# Build is owned by platform.hanzo.ai, not GitHub Actions. Platform reads this
+# file, schedules the image build onto the self-hosted arcd pools over the
+# native long-poll fabric, and pushes to GHCR — no GitHub-Actions hop.
+#
+# This repo previously built through .github/workflows/build-lux-kms.yml. That
+# path is dead: GitHub answers a workflow dispatch with 422 "Actions has been
+# disabled for this user", so pushes produced no build at all and the deployed
+# image silently drifted behind main.
+#
+# Schema: ~/work/hanzo/platform/docs/PLATFORM_CI.md §hanzo.yml.
+build:
+  matrix:
+    - { os: linux, arch: amd64 }
+  dockerfile: ./Dockerfile
+  context: .
+  image: ghcr.io/luxfi/kms
+  tag-pattern: "{{git.branch}}"
+  push: true
+  dispatch: native
+
+# No `deploy:` block. The kms Deployment in the hanzo namespace is kustomize-
+# managed and carries no operator CR, so there is nothing here for the Service-CR
+# rollout to target. Rolling the image stays a separate, explicit step.