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/README.md

@@ -22,13 +22,15 @@ deploy/k8s/
 applying `base/` directly — `base/` alone has no namespace and won't apply
 meaningfully on its own.
 
-## Routine deploys go through CI now
+## Routine deploys go through CI + ArgoCD now
 
 As of the GitLab CI/CD pipeline (`.gitlab-ci.yml`, see `../../VNCMAIL-SETUP.md`
-§ CI/CD), **pushing to `dev` auto-builds and auto-deploys** — you should not
-normally need to run `kubectl apply` for the sandbox by hand anymore. This
-guide's manual steps below are for first-time setup, the one-time secret
-creation CI deliberately never automates, and troubleshooting.
+§ CI/CD), **pushing to `dev` auto-builds and bumps the deploy tag; ArgoCD's
+`vncmail-dev` Application applies it** — you should not normally need to run
+`kubectl apply` for the sandbox by hand anymore, and CI never touches the
+cluster directly (it only ever talks to the registry and to this git repo).
+This guide's manual steps below are for first-time setup, the one-time
+secret creation CI/ArgoCD deliberately never automate, and troubleshooting.
 
 ## Production status
 
@@ -144,15 +146,23 @@ a bare username.
 
 ## 5. Update to a new build
 
-Normally you don't — CI's `deploy-dev` job does this automatically on every
-push to `dev`. To do it by hand (e.g. troubleshooting):
+Normally you don't — CI's `bump-dev` job + ArgoCD's automated sync do this
+on every push to `dev`. To do it by hand (e.g. troubleshooting, before
+automated sync is turned on):
 
 ```bash
 kubectl -n vncmail set image deploy/vncmail-plus \
   vncmail-plus=registry.gitlab.vnc.biz/gitlab-instance-b9b5cf2f/vncmail-plus:sha-<sha>
 ```
 
-Rollback: `kubectl -n vncmail rollout undo deploy/vncmail-plus`
+ArgoCD will overwrite this on its next sync unless you also update
+`deploy/k8s/overlays/dev/image-tag/kustomization.yaml` to match — that file
+is CI-owned (see its header comment), so a by-hand `set image` is only ever
+a temporary override, not a real fix.
+
+Rollback (bypassing ArgoCD temporarily): `kubectl -n vncmail rollout undo deploy/vncmail-plus`.
+The real rollback is reverting the commit that bumped the tag and letting
+ArgoCD re-sync.
 
 ---