feat(ci): pivot to ArgoCD GitOps, fix Traefik ingress after real-cluster check

Direct SSH access to the actual clusters (node1-3 "prod" HA, dev-k8s-1-3
"dev") revealed two things that made the previous design wrong:

1. Neither cluster has vncmail/vnc-ca namespaces or a bulwark ingress at
   all - the "live sandbox" referenced in this repo's docs/manifests was
   never actually applied anywhere. Both ingress.yaml's ingressClassName
   (public) and cert-manager issuer (letsencrypt-prod) were also wrong:
   both clusters run Traefik (class is literally named `traefik`), and
   only dev-k8s has any ClusterIssuer at all (`letsencrypt-staging`).
   node1-3 has zero ClusterIssuers configured.

2. dev-k8s already has ArgoCD installed, idle, zero Applications - more
   idiomatic to use it than have GitLab Runner execute kubectl directly.

Pivots .gitlab-ci.yml: build+push image, then commit the tag into a small
per-overlay Component (overlays/{dev,prod}/image-tag/) that ArgoCD's
Application watches - CI never touches the cluster, only the registry and
this repo. dev's Application (vncmail-dev) is registered and applied
already (manual sync for now, until the one-time namespace secret
bootstrap is done - see VNCMAIL-SETUP.md). prod's Application is
scaffolded in deploy/argocd/ but deliberately not applied - it targets a
different cluster (node1-3) that isn't registered with ArgoCD yet, and
there's still no real prod hostname/Stalwart/ClusterIssuer.

Fixes base/ingress.yaml to the real ingressClassName: traefik (was the
nginx-style `public`, which doesn't exist on either cluster) and gives
each overlay its own cert-manager issuer patch instead of one hardcoded
value, since dev and prod need different (or, for prod, nonexistent)
issuers.

deploy/k8s/base/ingress.yaml

@@ -1,27 +1,28 @@
-# Exposes VNCmail+ at vncmail.sandbox.vnc.de, alongside bulwark.sandbox.vnc.de.
-# MATCH YOUR CLUSTER — inspect the existing Bulwark ingress and copy its
-# ingressClassName + TLS/cert-manager annotations:
-#   kubectl get ingress -A | grep bulwark
-#   kubectl get ingress <bulwark-ingress> -n <ns> -o yaml
+# Both real clusters (node1-3 "prod", dev-k8s-1-3 "dev") run Traefik, not
+# nginx — confirmed via `kubectl get ingressclass` (class is literally named
+# `traefik`). Unlike nginx's restrictive 1MB default, Traefik has no default
+# request-body-size cap, so there's no equivalent needed for mail attachment
+# uploads (the old nginx.ingress.kubernetes.io/proxy-body-size annotation
+# this file used to carry is simply not applicable here).
+#
+# Host, TLS secretName, and cert-manager issuer are ALL overlay-specific now
+# (dev-k8s only has a `letsencrypt-staging` issuer; node1-3/prod has none
+# configured yet) — every overlay's patch-ingress.yaml must override the
+# CHANGEME placeholders below.
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: vncmail-plus
   annotations:
-    # cert-manager issuer — set to whatever bulwark.sandbox.vnc.de uses.
-    cert-manager.io/cluster-issuer: letsencrypt-prod
-    # Mail attachments can be large; raise the nginx body limit.
-    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
+    cert-manager.io/cluster-issuer: CHANGEME
 spec:
-  # microk8s ingress addon class is usually "public" (nginx). Confirm with
-  # `kubectl get ingressclass` and match bulwark's.
-  ingressClassName: public
+  ingressClassName: traefik
   tls:
     - hosts:
-        - vncmail.sandbox.vnc.de
+        - CHANGEME.invalid
       secretName: vncmail-plus-tls
   rules:
-    - host: vncmail.sandbox.vnc.de
+    - host: CHANGEME.invalid
       http:
         paths:
           - path: /