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/values.yaml

@@ -775,6 +775,25 @@ httpRoute:
 #                   argument, with the cert-manager behaviour it was measured
 #                   against, is in stalwart.mtaSts.ingressGroups in
 #                   _helpers.tpl.
+#                   Named BY INDEX over those groups —
+#                   <release>-stalwart-mta-sts-ingress, then -1, -2 — in this
+#                   repo's idiom (README/style guide section 4, as
+#                   homeassistant's routes and keycloak's realm Ingresses do
+#                   it). So the NAME DOES NOT SAY WHICH ISSUER it carries:
+#                   NOTES.txt prints that mapping, and it is the only place the
+#                   association is visible.
+#                   REORDERING THIS LIST IS NOT FREE. The index runs over the
+#                   issuer groups, which are derived from the list, so moving
+#                   one entry can change how many objects exist and which index
+#                   holds which issuer — renumbering objects that were not
+#                   themselves moved. Kubernetes recreates them, which takes
+#                   their Certificate objects along; nothing is RE-ISSUED,
+#                   because the Secrets survive (cert-manager only
+#                   owner-references a Secret with
+#                   --enable-certificate-owner-ref, which this cluster does not
+#                   set). That last part is a property of the CLUSTER and not
+#                   of this chart: with that flag on, a reorder costs a fresh
+#                   ACME request per renumbered object.
 #   Gateway mode  — ONE HTTPRoute with all the hostnames. Nothing differs per
 #                   host here (same path, same backend, no filter) and
 #                   spec.hostnames is a list, so one object says exactly what