Add image-based deployment for control panels

docker-compose.panel.yml deploys every service from a published image.
A control panel writes only a compose file and an .env into its project
directory, so the build: stanzas of docker-compose.yml cannot resolve
their context there.

CI pushes api, migrate, web and daemon images to the Gitea container
registry on v* tags. The migrate stage ships as its own image because
the panel compose runs it as a one-shot service before the API starts.

The web port is named HOST_PORT: panels reverse-proxy "the" port of an
installation and need to know which one that is when a stack publishes
more than one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/ci.yml

@@ -3,6 +3,7 @@ name: CI
 on:
   push:
     branches: [main, develop]
+    tags: ["v*"]
   pull_request:
     branches: [main]
 
@@ -95,3 +96,54 @@ jobs:
 
       - name: Build Daemon image
         run: docker build -f apps/daemon/Dockerfile -t gamepanel-daemon:ci .
+
+  # --- Publish images (tags only) ---
+  #
+  # docker-compose.panel.yml deploys from these images, so the stack can be
+  # installed on a server that has no checkout of this repository — that is
+  # what a control panel needs.
+  #
+  # Plain `docker build` + `docker push` on purpose: no buildx or bake, so the
+  # job runs on the same self-hosted runner as the build test above.
+  #
+  # Requires a REGISTRY_TOKEN secret with package write scope. The registry is
+  # this Gitea instance's own container registry; the panel pulls from it.
+  publish:
+    name: Publish images
+    runs-on: ubuntu-latest
+    needs: [lint, daemon]
+    if: startsWith(github.ref, 'refs/tags/v')
+    env:
+      REGISTRY: gits.hibna.com.tr/hibna
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Registry login
+        run: |
+          printf '%s' "${{ secrets.REGISTRY_TOKEN }}" |
+            docker login gits.hibna.com.tr -u "${{ github.actor }}" --password-stdin
+
+      - name: Resolve tag
+        run: echo "TAG=${GITHUB_REF#refs/tags/}" >> "$GITHUB_ENV"
+
+      # The API Dockerfile carries the migration runner as its own stage; it
+      # has to be pushed as a separate image because docker-compose.panel.yml
+      # runs it as a one-shot service before the API starts.
+      - name: API + migrate
+        run: |
+          docker build -f apps/api/Dockerfile -t "$REGISTRY/gamepanel-api:$TAG" .
+          docker build -f apps/api/Dockerfile --target migrate -t "$REGISTRY/gamepanel-migrate:$TAG" .
+          docker push "$REGISTRY/gamepanel-api:$TAG"
+          docker push "$REGISTRY/gamepanel-migrate:$TAG"
+
+      # VITE_API_URL is baked in at build time: the SPA calls /api on its own
+      # origin, which the image's nginx proxies to the api service.
+      - name: Web
+        run: |
+          docker build -f apps/web/Dockerfile --build-arg VITE_API_URL=/api             -t "$REGISTRY/gamepanel-web:$TAG" .
+          docker push "$REGISTRY/gamepanel-web:$TAG"
+
+      - name: Daemon
+        run: |
+          docker build -f apps/daemon/Dockerfile -t "$REGISTRY/gamepanel-daemon:$TAG" .
+          docker push "$REGISTRY/gamepanel-daemon:$TAG"