fix(stalwart): let the mode conflict, not the MTA-STS entry, name the defect

With BOTH routing modes on and an mtaSts entry missing its tlsSecretName,
the render reported

  mtaSts.hosts[0] (mta-sts.example.com) has no tlsSecretName, and in
  Ingress mode every entry needs one

which is true and is the wrong diagnosis: the values file's defect is that
ingress.enabled and httpRoute.enabled are both true, and "in Ingress mode"
is a claim about a configuration that is not coherent at all. Whoever met
it would add a tlsSecretName, re-run, and reach the real message one round
later - or conclude the MTA-STS feature was the problem.

Measured on this chart, not reasoned about. And it is the second occurrence
of a defect the parallel keycloak round of Gitea #122 found on its own
realm list, independently and in the same round, which is what makes it a
rule rather than one chart's story: a specific validation must not be
reachable in a state that a structural validation already rejects.

Ordering is not the fix and could not be - Helm renders templates in an
order a chart cannot pin, so this template may not assume the httproute
template's abort runs first. Scope is: the Ingress-mode MTA-STS block is
now gated on ingress.enabled AND NOT httpRoute.enabled, so in the
incoherent combination it validates nothing and the only fail left is the
one that names the real problem.

The per-entry guard is NOT dead by this - verified reachable with
ingress.enabled alone. Defaults, the unchanged CI fixture and the overlay
all still render byte-identically against origin/main, and the HTTPRoute
render test still holds 58 assertions over 21 charts.

stalwart/templates/stalwart.ingress.yaml

@@ -80,6 +80,24 @@ when this chart is publishing over an Ingress AND the list is non-empty. The
 mutual exclusion of the two modes is enforced once, in stalwart.httproute.yaml,
 and it is unconditional on mtaSts: a fail anywhere aborts the whole render.
 
+AND "not httpRoute.enabled" IS PART OF THAT GATE RATHER THAN REDUNDANT WITH
+IT. Without it this block's per-entry required() can fire while BOTH modes are
+on, and then the render reports "mtaSts.hosts[0] has no tlsSecretName, and in
+Ingress mode every entry needs one" - true, and the wrong diagnosis: the
+values file's defect is that both modes are on, and "in Ingress mode" is a
+claim about a configuration that is not coherent at all. Whoever met it would
+add a tlsSecretName, re-run, and reach the real message one round later, or
+conclude this feature was the problem. MEASURED on this chart before the gate
+was added, not reasoned about.
+
+Ordering is not the fix and could not be: Helm renders templates in an order a
+chart cannot pin, so this template may not assume the httproute template's
+structural abort runs first. SCOPE is the fix - with both modes on this block
+validates nothing, so the only fail left is the one that names the real
+problem. The generalisation (a specific validation must not be reachable in a
+state a structural validation already rejects) is the Lessons-Learned entry
+that the parallel keycloak round of Gitea #122 bought on its own realm list.
+
 WHAT THIS DELIBERATELY DOES NOT CARRY: ingress.annotations. Those belong to the
 WebUI/JMAP host - on the live installation they are its CORS configuration for
 the bulwark webmail - and a policy file served to sending MTAs has no use for
@@ -91,7 +109,8 @@ does not create a DOMAIN. Whether Stalwart answers for mta-sts.<domain> depends
 on <domain> existing in its data store, which is not in any chart value (see
 values.yaml, line 1 onwards, and the mtaSts block).
 */ -}}
-{{- if .Values.ingress.enabled }}
+{{- $httpRoute := .Values.httpRoute | default dict }}
+{{- if and .Values.ingress.enabled (not $httpRoute.enabled) }}
 {{- $mtaSts := fromYaml (include "stalwart.mtaSts.ingressGroups" .) }}
 {{- if $mtaSts.order }}
 {{- $group := include "stalwart.ingressNodeGroup" . }}