ci(deploy): deploy the stack to Talos on merge to main (closes #175) (#176)

## What & why

The chart has been deployable by hand since #25 and linted in CI since #168. This makes a
merged PR actually ship it to the Talos VM on the lab server.

`.gitea/workflows/deploy.yaml` runs on a push to `main` (a squash-merged PR) and on manual
dispatch:

1. **Tunnel** — neither the Kubernetes API nor the in-cluster registry is publicly reachable,
   so 6443, 30500 and 30141 are forwarded over the same SSH hop into the Fedora host that the
   Gitea-runner pipeline uses (`ssh -p 6667 user@labs.respellion.tech`).
2. **Images** — `make k8s-images K8S_REGISTRY=localhost:30500`, pushed *through* the tunnel.
3. **Deploy** — `make k8s-reseed TALOS_HOST=… K8S_REGISTRY=<vm-ip>:30500`, pulled by the node
   from its own NodePort.
4. **Roll** — `rollout restart` + `rollout status` on the nine repo deployments.
5. **Smoke** — `GET /openbaar/register` through the openbaar portal.

Three decisions worth the review:

- **One registry, two names.** The push target (`localhost:30500`, the tunnel) and the pull
  target (`<vm-ip>:30500`, the node's own NodePort) address the same store. The pull name has
  to be the one in the node's registry-mirror patch, which is what makes plain HTTP acceptable.
- **`k8s-reseed`, not `k8s-up`.** A Job's pod template is immutable, so a chart change to any
  bootstrap Job would otherwise fail the upgrade with `cannot patch … with kind Job`. The Jobs
  are idempotent by design, so re-running them every deploy is safe and removes that whole
  class of failure. Cost: a few minutes per deploy, and `seed-zaaktype` needs egress from the VM.
- **No re-run of the checks.** PR CI is the merge gate, so `main` is green by construction.
  Deploys **queue** (`cancel-in-progress: false`) — a `helm upgrade` killed half-way leaves the
  release in `pending-upgrade` and has to be unwedged by hand.

Settings on the repo (already added): secrets `TALOS_SSH_KEY` and `TALOS_KUBECONFIG`
(base64, and its `server:` must be `https://127.0.0.1:6443` — Talos puts `127.0.0.1` in the
apiserver cert SANs, so TLS still verifies through the tunnel); variables `TALOS_VM_IP`
(default `192.168.122.173`) and `TALOS_HOST` (default `localhost`).

Closes #175

## Definition of Done

- [x] Linked Gitea issue (above).
- [ ] Failing test committed before the implementation — **n/a**: this is a deployment
      workflow with no unit under test. Its check is the run itself: `rollout status` and the
      public-register smoke both have to pass or the job fails. `make k8s-lint` / `make k8s-drift`
      (#168) already gate the chart it deploys.
- [x] Implementation — one workflow file, no production code touched.
- [x] Conventional Commits referencing the issue (`refs #175`).
- [ ] CI green — awaiting the run on this PR.
- [x] `docker compose up` unaffected — no service, image or compose file is touched.
- [x] Docs updated — `docs/runbooks/kubernetes-talos.md` §9 (the tunnel, the two registry
      names, the secrets table, the smoke) and a pointer from `docs/runbooks/ci.md`.
- [x] No ADR needed: no new dependency (kubectl/helm/crane are already prerequisites of the
      `k8s-*` targets), no service boundary moved, no CLAUDE.md §8 rule bent.
- [ ] Demo note — not user-visible.

## Notes for reviewers

- **The first deploy is the real test.** It cannot be dry-run: the tunnel, the secrets and the
  registry only exist on the lab server. Merging is how we find out; `Pods on failure` dumps
  `get pods,jobs` if it doesn't.
- **Known gap — the portals still aren't browsable.** PKCE needs a secure context, so a
  NodePort on an IP can't serve them (runbook §5); they need `make k8s-portals` or an SSH
  forward. Giving the server a hostname + TLS is the follow-up, and is where `TALOS_HOST`
  stops defaulting to `localhost`.
- **Databases are `emptyDir`.** Any change to a database pod's template wipes it; the
  `k8s-reseed` in the deploy re-runs the bootstrap, so the stack recovers, but submitted
  registrations do not. Persistence is runbook §6.

🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #176

.gitea/workflows/deploy.yaml

@@ -27,10 +27,6 @@ jobs:
       # `kubectl port-forward` — runbook §5. Override with repo variables.
       TALOS_VM_IP: ${{ vars.TALOS_VM_IP }}
       TALOS_HOST: ${{ vars.TALOS_HOST }}
-      # Set it and the stack is published over TLS on <sub>.<domain> by the
-      # in-cluster edge (ADR-0035, runbook §10). Empty = NodePorts, as before.
-      PUBLIC_DOMAIN: ${{ vars.PUBLIC_DOMAIN }}
-      PUBLIC_EMAIL: ${{ vars.PUBLIC_EMAIL }}
     steps:
       - uses: https://github.com/actions/checkout@v4
 
@@ -93,13 +89,7 @@ jobs:
       # The jobs are idempotent, and deleting them first is what keeps a changed
       # Job template from wedging the upgrade (`cannot patch … with kind Job`).
       - name: Deploy the chart
-        run: |
-          set -euo pipefail
-          publish="${PUBLIC_DOMAIN:+--set public.domain=$PUBLIC_DOMAIN --set public.email=${PUBLIC_EMAIL:-}}"
-          make k8s-reseed \
-            TALOS_HOST=${TALOS_HOST:-localhost} \
-            K8S_REGISTRY=${TALOS_VM_IP:-192.168.122.173}:30500 \
-            K8S_SET="$publish"
+        run: make k8s-reseed TALOS_HOST=${TALOS_HOST:-localhost} K8S_REGISTRY=${TALOS_VM_IP:-192.168.122.173}:30500
 
       # `dev` is a mutable tag and helm sees an unchanged pod template, so the
       # new images only land on a restart (pullPolicy is already Always).
@@ -115,12 +105,6 @@ jobs:
       - name: Smoke the public register
         run: curl -fsS --retry 10 --retry-delay 6 --retry-all-errors http://localhost:30141/openbaar/register
 
-      # Cluster-wide, not just `big`: the first thing that can fail is the registry
-      # in its own namespace, and a scheduling problem shows up in the events, not
-      # in `rollout status` — which only ever says "timed out waiting".
-      - name: Pods and events on failure
+      - name: Pods on failure
         if: failure()
-        run: |
-          kubectl get pods -A -o wide || true
-          kubectl -n big get jobs || true
-          kubectl get events -A --sort-by=.lastTimestamp | tail -30 || true
+        run: kubectl -n big get pods,jobs || true

docs/runbooks/kubernetes-talos.md

@@ -366,36 +366,6 @@ immutable, so `helm upgrade` is rejected with `cannot patch "…" with kind Job`
 every time a PR is squash-merged to `main` (and on demand via *Run workflow*). PR CI is the
 merge gate, so the workflow deploys without re-running the checks.
 
-**Prerequisite: the VM must have been installed with the §1 patch.** A stock Talos config
-gives you a node that still carries the control-plane taint and knows nothing about the
-plain-HTTP registry, and the deploy hits those in that order: the `registry` pod sits
-`Pending` until `rollout status` times out, and once that is fixed every repo image fails to
-pull. Two separate fixes:
-
-```bash
-# on the Fedora host — 1. let workloads onto the only node (§1)
-export KUBECONFIG=~/talos-kubeconfig-local
-kubectl taint node --all node-role.kubernetes.io/control-plane-
-
-# 2. trust the in-cluster registry over plain HTTP (§2)
-cat > /tmp/registry-patch.yaml <<'YAML'
-machine:
-  registries:
-    mirrors:
-      "<TALOS_VM_IP>:30500":
-        endpoints:
-          - http://<TALOS_VM_IP>:30500
-YAML
-talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/registry-patch.yaml
-```
-
-Keep those two apart. On Talos 1.14 a patch that also sets
-`cluster.allowSchedulingOnControlPlanes` is rejected with *".cluster.allowSchedulingOnControlPlanes
-is already set in v1alpha1 config"* — the field moved out of the v1alpha1 schema, the same way
-`machine.install` did (§1) — and the rejection takes the whole patch with it, so the mirror
-silently doesn't land either. `kubectl taint` is the documented way (§1); it is undone if the
-node ever re-registers, which is a reboot, not a deploy.
-
 The cluster's API and registry are not exposed publicly, so the job forwards them over the
 same SSH hop the Gitea-runner pipeline uses:
 
@@ -427,26 +397,6 @@ Settings, all on the repository in Gitea:
 The last step smokes `GET /openbaar/register` through the openbaar portal, which exercises
 portal → Caddy → BFF → projection. An empty register passes; a 502 does not.
 
-### Reaching the portals from a laptop
-
-The deployed portals are pinned to `http://localhost:30180` for Keycloak (§5), so a browser
-needs **all five** browser-facing ports on its own localhost — the portal alone is not
-enough, and a missing Keycloak shows up as `ERR_CONNECTION_REFUSED` on
-`/realms/*/.well-known/openid-configuration` followed by an opaque `ERROR Error: [object Object]`.
-`make k8s-portals` does this when kubectl can reach the cluster; through the lab server one
-SSH does it without a kubeconfig at all:
-
-```bash
-ssh -N -p 6667 \
-  -L 30140:<TALOS_VM_IP>:30140 -L 30141:<TALOS_VM_IP>:30141 \
-  -L 30142:<TALOS_VM_IP>:30142 -L 30143:<TALOS_VM_IP>:30143 \
-  -L 30180:<TALOS_VM_IP>:30180 \
-  user@labs.respellion.tech
-```
-
-Then the §5 table's URLs work as written. The admin UIs (OpenZaak, Flowable, …) need no
-forward — they are server-rendered, so the VM's address is fine.
-
 Not covered: the portals still need `make k8s-portals` (or an SSH forward) to be usable in a
 browser, because PKCE needs a secure context (§5). Giving the server a hostname + TLS is the
 upgrade path.