feat(iam): wire ZITADEL SMTP through envVarsSecret

ZITADEL must send verification codes, and it only speaks SMTP. Route that at
the smtp-gotify relay so codes reach Gotify and the phone.

The settings go in as a ZITADEL_DEFAULTINSTANCE_SMTPCONFIGURATION_* envFrom
secret, not as configmapConfig. Editing configmapConfig makes ArgoCD stop
managing the rendered zitadel-config-yaml ConfigMap, which the Deployment still
mounts; that twice left the IdP one restart away from failing. Env vars override
the same keys and leave that ConfigMap alone.

Validated with helm template 10.4.0: envFrom appears on both ZITADEL containers
and zitadel-config-yaml still renders.

k8s/infra/iam/zitadel-values.yaml

@@ -145,6 +145,20 @@ setupJob:
 replicaCount: 2
 revisionHistoryLimit: 3
 
+# Notification delivery. ZITADEL sends verification codes and password resets
+# by SMTP only, and this cluster has no mail path, so every user sits at
+# verified_email = empty and cannot finish a first login.
+#
+# The settings go in through envVarsSecret rather than configmapConfig on
+# purpose: changing configmapConfig makes ArgoCD stop managing the rendered
+# `zitadel-config-yaml` ConfigMap, which the Deployment still mounts, so the
+# next pod restart fails. An envFrom secret overrides the same keys with no
+# effect on that ConfigMap.
+#
+# Target is the in-cluster smtp-gotify relay, which forwards to Gotify so the
+# codes arrive on the phone.
+envVarsSecret: zitadel-smtp-env
+
 # Best practice: a PDB guarantees at least one API pod stays available during
 # voluntary disruptions (node drain, rolling upgrade). Without it a drain can
 # take both replicas down at once. minAvailable 1 is correct for 2 replicas;