Merge origin/main: Renovate's stalwart v0.16.26 into this branch

Renovate automerged the stalwart app patch onto main while this PR was open
(1fd6c56: 1.3.0+upv0.16.25 -> 1.3.1+upv0.16.26), which collided with the major
this PR gives the same chart. The PR went mergeable: false, with an approval and
green checks - the conflict was the only thing in the way.

Resolution: version: 2.0.0+upv0.16.26 with appVersion: "v0.16.26". My major
absorbs their patch rather than being added to it, and the +up suffix follows
appVersion as the scheme requires - verified, suffix == appVersion with dashes
normalised.

Also corrects the justification comment above that line, which had gone stale
in a misleading direction: it argued MINOR, from a diff, for the two previous
rounds (#96's spread constraint and PDB, both gated on a computed replica count
the chart never reaches; #123's MTA-STS routes, whose list ships empty) - both
of which rendered byte-for-byte identically against the previous version. It
then sat directly above a 2.0.0. The comment now says why #5 fails that same
test on every count: a new value, a changed rendered form, and an object that
reaches a RUNNING release on upgrade and changes what can reach the pod. The
old evidence is kept as history rather than deleted, because the contrast is
the useful part.

A merge rather than a rebase, deliberately: the branch is already pushed and
force-pushing a reviewed branch is destructive, so main comes in instead.

Part of #5

stalwart/Chart.yaml

@@ -18,18 +18,27 @@ type: application
 # all three of latest / v0.16 / v0.16.24 resolved to one digest pushed seconds
 # apart, so either floating name would change the running image with no commit
 # in this repository and nothing to report it.
-# MINOR, not major, and the evidence is a diff rather than a judgement. That
-# held for the per-group spread constraint and PodDisruptionBudget of Gitea #96
-# (both gated on the COMPUTED replica count being >= 2, and the chart ships
-# full: 1 / mx: 0) and it holds again for the MTA-STS routes of Gitea #123: the
-# list is the switch and it ships EMPTY, so no object is added and no value
-# becomes required in either routing mode. `helm template` against the previous
-# version renders byte-for-byte identically for the defaults AND for
-# ci/stalwart/test-values.yaml as it stands on origin/main - measured, both
-# empty diffs. New optional values with unchanged defaults is exactly the minor
-# case (README, "Versioning").
-version: 2.0.0+upv0.16.25
-appVersion: "v0.16.25"
+# MAJOR for Gitea #5, and the reason is that the test the two MINOR rounds
+# below passed is the one this round FAILS. Those rounds argued from a diff:
+# the spread constraint and PodDisruptionBudget of #96 (both gated on the
+# COMPUTED replica count being >= 2, with the chart shipping full: 1 / mx: 0)
+# and the MTA-STS routes of #123 (the list is the switch and it ships EMPTY)
+# added no object and made no value required, so `helm template` against the
+# previous version rendered byte-for-byte identically for the defaults AND for
+# ci/stalwart/test-values.yaml - measured, both empty diffs. New optional
+# values with unchanged defaults is exactly the minor case.
+#
+# #5 is the opposite on every count. networkPolicy.ingressController is new,
+# the policy's rendered form changes, and - the part that decides it - the
+# object reaches a RUNNING release on the next upgrade and changes what can
+# reach the pod. A wrong source there makes a service mute, which is precisely
+# the breaking-change case (README, "Versioning"). The app-version patch
+# Renovate landed as 1.3.1 is absorbed by this major rather than added to it.
+#
+# Note for whoever bumps this next: the suffix tracks appVersion, so a major
+# here keeps the +up<appVersion> it was merged with.
+version: 2.0.0+upv0.16.26
+appVersion: "v0.16.26"
 
 maintainers:
   - name: jklein