refactor(stalwart): name the MTA-STS Ingress objects by index, per the corrected rule

Maintainer's decision, and it reverses this chart's naming rather than the
style guide's rule. The objects become

  <release>-stalwart-mta-sts-ingress, -1, -2, ...

in this repo's idiom ({{ if $i }}-{{ $i }}{{ end }}), the same as
homeassistant's routes and keycloak's realm Ingresses, inlined in the
template instead of behind a helper of its own.

WHY IT GOES THIS WAY. This chart named by issuer, reading the style guide's
index rule as resting on "a route holds no state and no certificate" and
observing that these objects hold one. That reading was right and the
rule's STATED REASON was wrong: the parallel #122 round named by index,
cited the same rule as binding, and entered keycloak into it - whose realm
Ingresses hold certificates too. Two charts did opposite things for one
shape, and the rule had been extended onto cases its own precondition
excluded. #125 is merged and published, so the reason is repaired and the
naming unified on index; keycloak is not touched.

What actually carries the index rule, in three steps that have different
standing and are written as such in the template header and the style guide:
cert-manager here runs WITHOUT --enable-certificate-owner-ref (MEASURED by
the maintainer - absent from the Deployment's args and from the
ControllerConfiguration its --config names, which carries only
kind: ControllerConfiguration and enableGatewayAPI: true); by that default
the Certificate is collected with its Ingress but the SECRET IS NOT
(DOCUMENTED behaviour, not measured here), so a rename recreates the
Certificate object against a surviving secret and issues nothing; and NO
RENAME WAS APPLIED against a cluster. The promise therefore hangs on a
cluster-level flag this repository does not control - with it on, a reorder
would cost a fresh ACME request per renumbered object.

UNCHANGED: the structure. One Ingress per distinct clusterIssuer, one rule
per host, tls grouped by secret, and the abort when one secret spans two
issuers - grouping is a cert-manager question and naming is a style
question, and they are independent.

TWO THINGS THE RENAME OBLIGES.

1. NOTES.txt now prints the mapping - index, object name, issuer, secrets
   and hosts per object, the way keycloak's does for its realms - because
   the name no longer carries the issuer and nothing else in the cluster
   says which object holds which.
2. The reordering hazard is documented as SHARPER than homeassistant's:
   there an index names a host, here it names an issuer GROUP derived from
   the list, so moving one entry can change the grouping and renumber
   objects that were not themselves moved.

AN ASYMMETRY WITH keycloak, named in the template header: there both modes
render one object per entry, so the index question arises twice. Here it
arises on the Ingress side ONLY - Gateway mode renders one HTTPRoute
carrying every hostname, because TLS is none of the route's business, so
there is no index and no name to go stale.

Version stays 1.3.0+upv0.16.25: nothing is published yet, so nothing is
being renamed in a release.

Re-measured after the rename, not assumed: three empty helm template diffs
against origin/main (defaults, CI fixture, overlay), helm lint --strict
clean three ways, every abort path still firing with the structural one
still winning over the per-entry one, the schema still rejecting
mtaSts.enabled, and the HTTPRoute render test still at 64 assertions over
22 charts - object names are not assertions.

stalwart/templates/NOTES.txt

@@ -331,20 +331,45 @@ WEB UI AND JMAP — INGRESS MODE (ingress.enabled: true, httpRoute.enabled: fals
   Ingress resolves to a port that answers nothing.
 {{- if $mtaStsHosts }}
 
-MTA-STS — {{ len $mtaStsHosts }} POLICY ROUTE(S), INGRESS MODE
+{{- $mtaStsGroups := fromYaml (include "stalwart.mtaSts.ingressGroups" .) }}
+
+MTA-STS — {{ len $mtaStsHosts }} POLICY HOST(S) IN {{ len $mtaStsGroups.order }} INGRESS OBJECT(S), INGRESS MODE
   All of them →  node group "{{ $ingressGroup }}", path {{ $mtaStsPath }} only (pathType Exact)
-{{ range $entry := $mtaStsHosts }}
-  https://{{ $entry.host }}{{ $mtaStsPath }}
-      secret {{ $entry.tlsSecretName }}{{ if $entry.clusterIssuer }}, requested from the "{{ $entry.clusterIssuer }}" cluster issuer{{ else }}, NO cluster issuer set — this release does not request that certificate, it has to exist already{{ end }}
+
+  ONE OBJECT PER CLUSTER ISSUER, NAMED BY INDEX — so the name does not say
+  which issuer it carries, and this is the mapping. Read it here rather than
+  guessing from the object names:
+{{- range $i, $issuer := $mtaStsGroups.order }}
+{{- $grp := index $mtaStsGroups.groups $issuer }}
+
+  {{ printf "%s-mta-sts-ingress%s" $release (ternary "" (printf "-%d" $i) (eq $i 0)) }}
+      cluster issuer: {{ if $issuer }}"{{ $issuer }}" — cert-manager requests these certificates{{ else }}NONE — no annotation, so this release requests nothing; every secret below has to exist already{{ end }}
+  {{- range $secret := $grp.tlsOrder }}
+      secret {{ $secret }}
+    {{- range $host := index $grp.tls $secret }}
+        https://{{ $host }}{{ $mtaStsPath }}
+    {{- end }}
+  {{- end }}
 {{- end }}
 
-  One Ingress object PER CLUSTER ISSUER, not one per host: the cert-manager
-  issuer is an object-level ANNOTATION while the TLS secret is a per-entry
-  field, so one object cannot both request a certificate and leave another
+  Why one object per issuer rather than one for everything: the cert-manager
+  issuer is an object-level ANNOTATION while the TLS secret is a per-tls-entry
+  field, so a single object cannot both request a certificate and leave another
   host's secret alone. Hosts sharing a secret share one tls: entry, so one
   certificate with several names is requested once instead of once per host:
     kubectl -n {{ .Release.Namespace }} get ingress -l app={{ $release }}
 
+  AND MIND THE ORDER OF mtaSts.hosts. The index above runs over the issuer
+  GROUPS, which are derived from the list — so reordering entries can change
+  how many objects there are and which index carries which issuer, renumbering
+  objects that were not themselves moved. Kubernetes then deletes and recreates
+  them, which takes their Certificate objects with them. No certificate is
+  RE-ISSUED by that, because the Secrets survive it (cert-manager leaves them
+  alone unless it runs with --enable-certificate-owner-ref, which this cluster
+  does not set) — but that is a property of the CLUSTER, not of this chart. If
+  that flag is ever switched on, a reorder means a fresh ACME request per
+  renumbered object.
+
   TWO THINGS THIS RELEASE DOES NOT DO, AND BOTH ARE SILENT WHEN MISSING:
 
     1. IT DOES NOT CREATE THE DOMAIN. The domains live in Stalwart's data