feat(ci): deploy to k3s straight from the pipeline (drop Flux plan)

Push to main = release: after build, a deploy job pins each app image to the
commit SHA (kustomize edit set image), kubectl-applies fleet/apps and waits
for the rollouts. The runner already runs in-cluster, so it reaches the API
server on the in-cluster service IP with a kubeconfig for the new ci-deployer
ServiceAccount (namespace-scoped admin, KUBECONFIG_B64 repo secret).

The drafted Flux sync/image-automation layer is removed — a GitOps controller
plus bot tag-bump commits is more machinery than a single-node cluster needs.
Sortable image tags and $imagepolicy markers go with it.

Also: per-router ACME-safe HTTP->HTTPS redirects for the app ingresses,
platform-api prod config completed (Authentik JWT/JWKS + admin API, Stalwart
via the cni0 gateway IP, OCIS/cold-storage placeholders until those tiers
exist) and the secrets template/README updated to match.

infrastructure/production/fleet/README.md

@@ -2,15 +2,16 @@
 
 k3s manifests for the dezky **application tier** that runs in-cluster on the
 Hetzner AX41 node (see `../host/README.md` for the host layer). This layer
-deploys the three first-party apps:
+deploys the first-party apps:
 
 | App | Image | Public host | Internal Service |
 |-----|-------|-------------|------------------|
 | platform-api | `git.lastcloud.io/ronnibaslund/dezky/platform-api` | `api.dezky.eu` | `platform-api.dezky-apps:3001` |
 | portal | `git.lastcloud.io/ronnibaslund/dezky/portal` | `app.dezky.eu` | `portal.dezky-apps:3000` |
 | booking | `git.lastcloud.io/ronnibaslund/dezky/booking` | `booking.dezky.eu` | `booking.dezky-apps:3000` |
+| operator | `git.lastcloud.io/ronnibaslund/dezky/operator` | `operator.dezky.eu` | `operator.dezky-apps:3000` |
 
-All three live in the `dezky-apps` namespace. The data tier (Postgres/Mongo/
+All of them live in the `dezky-apps` namespace. The data tier (Postgres/Mongo/
 Redis), Authentik and OCIS are added by other parts of the fleet layer and live
 in their own namespaces; these manifests reference them by cluster DNS only.
 
@@ -20,11 +21,16 @@ in their own namespaces; these manifests reference them by cluster DNS only.
 apps/
 ├── kustomization.yaml          # bundles the non-secret resources
 ├── namespace.yaml              # dezky-apps namespace
+├── redirect-middleware.yaml    # per-router HTTP→HTTPS redirect (ACME-safe)
 ├── platform-api.yaml           # Deployment + Service + Ingress (api.dezky.eu)
 ├── platform-api-config.yaml    # non-secret ConfigMap (Stalwart URL, toggles)
 ├── portal.yaml                 # Deployment + Service + Ingress (app.dezky.eu)
 ├── booking.yaml                # Deployment + Service + Ingress (booking.dezky.eu)
+├── operator.yaml               # Deployment + Service + Ingress (operator.dezky.eu)
 └── secrets.example.yaml        # SECRET TEMPLATE — never commit real values
+ci/
+├── gitea-runner.yaml           # in-cluster Gitea Actions runner (+ dind)
+└── ci-deployer.yaml            # ServiceAccount/RBAC the CI deploy job uses
 ```
 
 ## Prerequisites (other fleet layers)
@@ -54,26 +60,58 @@ booking.dezky.eu   → <AX41 IP>
 
 ## Deploy
 
+**Push to main = release.** CI (`.gitea/workflows/ci.yml`, runner in-cluster —
+see `ci/gitea-runner.yaml`) typechecks + tests, builds each app image tagged
+`:latest` and the commit SHA, pushes to the Gitea registry, then the deploy job
+pins the kustomization to that SHA (`kustomize edit set image`), runs
+`kubectl apply -k apps/` and waits for the rollouts. No GitOps controller, no
+bot commits — the pipeline that built the image deploys it.
+
+One-time bootstrap for the deploy job's cluster access:
+
 ```bash
-# 1) Apply real Secrets out-of-band (NOT from git). Copy the template,
-#    fill in values, apply — or render SealedSecrets from it.
+# 1) ServiceAccount + RBAC (admin scoped to dezky-apps).
+kubectl apply -f ci/ci-deployer.yaml
+
+# 2) Mint a kubeconfig from its token and store it as the Gitea repo secret
+#    KUBECONFIG_B64 (repo Settings → Actions → Secrets). API server address is
+#    the in-cluster service IP — the runner's jobs run inside the cluster.
+TOKEN=$(kubectl -n dezky-apps get secret ci-deployer-token -o jsonpath='{.data.token}' | base64 -d)
+CA=$(kubectl -n dezky-apps get secret ci-deployer-token -o jsonpath='{.data.ca\.crt}')
+cat <<EOF | base64 | pbcopy   # paste into the KUBECONFIG_B64 secret
+apiVersion: v1
+kind: Config
+clusters:
+  - name: dezky
+    cluster:
+      server: https://10.43.0.1:443
+      certificate-authority-data: $CA
+users:
+  - name: ci-deployer
+    user:
+      token: $TOKEN
+contexts:
+  - name: dezky
+    context: {cluster: dezky, user: ci-deployer, namespace: dezky-apps}
+current-context: dezky
+EOF
+```
+
+Manual / break-glass deploy (first boot, runner down, secrets changed):
+
+```bash
+# Real Secrets are applied out-of-band (NOT from git) and the Deployments
+# won't start without them. Copy the template, fill in values, apply.
 cp apps/secrets.example.yaml /tmp/dezky-secrets.yaml
 $EDITOR /tmp/dezky-secrets.yaml          # fill every REPLACE / PASSWORD
 kubectl apply -f /tmp/dezky-secrets.yaml
 rm /tmp/dezky-secrets.yaml
 
-# 2) Apply the app tier.
 kubectl apply -k apps/
-
-# 3) Watch rollout + cert issuance.
 kubectl -n dezky-apps rollout status deploy/platform-api
 kubectl -n dezky-apps get ingress,certificate
 ```
 
-Images are pushed by CI (`.gitea/workflows/ci.yml`) to the Gitea registry. The
-manifests reference `:latest` for convenience; for real releases, set the image
-tag to the commit SHA and bump it per deploy (or wire Fleet/ArgoCD to do it).
-
 ## Required env / secrets
 
 Non-secret config lives in `platform-api-config.yaml` (ConfigMap) and inline
@@ -85,12 +123,17 @@ Non-secret config lives in `platform-api-config.yaml` (ConfigMap) and inline
 | Key | Purpose | How to get it |
 |-----|---------|---------------|
 | `MONGODB_URI` | Portal/app database connection | From the in-cluster Mongo credentials |
-| `SCHEDULING_CREDENTIAL_KEY` | AES key encrypting stored scheduling creds | `openssl rand -hex 32` |
+| `SCHEDULING_CREDENTIAL_KEY` | AES key encrypting stored scheduling creds | `openssl rand -hex 32` — back up |
 | `STALWART_ADMIN_PASSWORD` | JMAP management auth | **Same value** as the host `config.env` |
 | `STALWART_WEBHOOK_SECRET` | Audit webhook HMAC | **Same value** as the host `config.env` |
+| `AUTHENTIK_API_TOKEN` | Authentik admin API (provisioning) | `dezky-auth/authentik-secret.AUTHENTIK_BOOTSTRAP_TOKEN` |
+| `AUDIT_SIGNING_KEY` | Audit hash-chain signing key | `openssl rand -hex 32` — back up |
+| `AUDIT_COLD_ACCESS_KEY` / `AUDIT_COLD_SECRET_KEY` | Hetzner Object Storage IAM | placeholder until the bucket exists |
+| `OCIS_SVC_PASSWORD` | OCIS service user (files tier) | placeholder until OCIS is deployed |
 
-ConfigMap (`platform-api-config`): `STALWART_API_URL`, `STALWART_ADMIN_USER`,
-`STALWART_PROVISIONING_ENABLED`. `PORT` and `DEZKY_ENV` are set inline.
+Non-secret runtime config (Authentik issuer/audience/JWKS, Stalwart URL, OCIS
+URL, cold-storage endpoint, feature toggles) lives in
+`platform-api-config.yaml`. `PORT` and `DEZKY_ENV` are set inline.
 
 ### portal (`portal-secrets`)