feat!: NetworkPolicy in the last five charts - the sweep is complete

matrix-synapse, paperless-ngx, freesailarr, valkey, stalwart. One major each.
All 29 installable charts plus template-chart now render a policy, and
ci/run-networkpolicy-test.sh passes over all 30 with 206 assertions held.

MATRIX-SYNAPSE renders TWO policies, one per workload, and the split is the
decision in that file. Synapse federates - it must be able to reach any
homeserver on the internet, so 443 and 8448 go to any destination - while the
delegation nginx serves two static JSON documents and calls nobody, so its
egress is DNS and nothing else. A single policy over both pods would have to
permit the union, handing full federation reach and the database port to an
nginx whose job is to return a constant, and it would read as one decision
rather than as a widening. networkPolicy.egress.extraPorts deliberately does
not reach the delegation policy for the same reason.

PAPERLESS-NGX names the two pods of its own release that this object does NOT
cover: the valkey subchart's pod, which carries its own labels and needs no
cover because the valkey chart ships a tighter policy of its own; and the
consume CronJob's pods, whose pod template carries NO LABELS AT ALL, so no
podSelector can match them. That second one is a real gap in the convention. It
is tolerable only because the job moves files between mounted volumes and
reaches the SMB share through a CSI volume the node mounts - the pod opens no
connection of its own - and if that ever changes the CronJob needs labels
before it can need a policy.

FREESAILARR is ten containers in one pod behind a VPN, and simpler than that
sounds: they share a network namespace, so all inter-container traffic is
localhost and no policy sees any of it. Because the namespace belongs to
gluetun, everything the *arr containers send is encapsulated before it leaves,
so three rules describe the whole outbound surface - DNS, UDP 51820 for the
tunnel, and 443 for gluetun's server-list API, which cannot go through the
tunnel because it runs before the tunnel exists. The tunnel rule is the one
that can break this chart and also the best covered: gluetun's health server
answers 200 only while the tunnel is up and all three of its probes address it,
so a blocked 51820 is a pod that never goes Ready - in the install-test, which
brings up a real tunnel.

VALKEY AND STALWART, the two charts that had a policy before this issue, are
pulled onto the convention without a single rule changing. What changed:

  - the reasoning moved out of "#" comments, which are part of the rendered
    object and travel into the cluster, into template comments. Both files
    failed the new check; that is what it is for.
  - stalwart gains networkPolicy.ingressController, which fixes a hole its own
    comment described without being able to solve: it advised putting the
    controller's namespace into allowedNamespaces, which is namespace-granular
    and would have opened the http port to every pod in kube-system.
  - stalwart's example was WRONG and is corrected. It suggested
    ["ingress-nginx"]; measured on 2026-10-14, ingress-nginx is gone from this
    cluster entirely and the controller is rke2-traefik in kube-system. A policy
    written against the old one would have been accepted, looked strict, and
    silently blocked all web traffic.

Their justified specifics are untouched: valkey stays Ingress-only, because it
opens no outbound connection and an egress rule would constrain nothing while
making the object look stricter; and it keeps 6379 restricted by source with no
probeSources at all, which is safe only because all three of its probes are
exec probes and put no packet on the network. The convention was written to
accommodate both, and homeassistant and satisfactory now invoke valkey's rule
in the other direction.

ONE CHANGE TO THE TEST, forced by a structural fact rather than by convenience:
the rendered-comment assertion now skips documents from a SUBCHART. A
dependency is fetched from the Helm registry, not from the copy in this
repository, so the policy paperless-ngx and stalwart bundle is whatever valkey
version is PUBLISHED - and nothing in the parent chart can change its rendered
comments. Holding the parent responsible would have made the test unfixable
until valkey's next release and would fail a chart for a file its own diff does
not contain. The subchart's own pull request is where it is caught, because this
test runs over every chart including valkey itself. All twelve failure paths
were re-run against the change.

Part of #5

valkey/templates/valkey.networkpolicy.yaml

@@ -1,27 +1,64 @@
+{{- /*
+NetworkPolicy for valkey (Gitea #5).
+
+THIS CHART AND stalwart ARE THE TWO THAT HAD A POLICY BEFORE #5, so the
+convention was derived from them rather than imposed on them. What changed here
+is the FORM and not a single rule: the reasoning moved out of "#" comments,
+which are part of the rendered object and travel into the cluster, into template
+comments, which render nothing. ci/run-networkpolicy-test.sh now fails on a
+rendered "#", and this file was one of the two that failed it.
+
+TWO THINGS THAT DELIBERATELY DID NOT CHANGE, because they are right and the
+convention was written to accommodate them:
+
+1. INGRESS ONLY. This instance opens no outbound connection of its own - no
+   replication, no cluster bus - so an egress rule here would constrain nothing
+   while making the object look stricter than it is. policyTypes names only
+   what there is something to restrict. homeassistant and satisfactory invoke
+   the same rule in the other direction, for outbound traffic nobody can
+   enumerate.
+
+2. 6379 IS RESTRICTED BY SOURCE, with no probeSources value anywhere in this
+   chart - and that combination is only safe because of a detail worth knowing:
+   ALL THREE PROBES HERE ARE EXEC PROBES. An exec probe runs inside the
+   container through the kubelet's runtime and puts no packet on the network, so
+   there is no kubelet traffic to let through and nothing to accommodate. A
+   chart with an httpGet or tcpSocket probe on this port could NOT restrict it
+   this way - it would need the worker node's IP, which no chart can know, and
+   the pod would never become Ready without it. minecraft-server is tight for
+   the same reason; every web app in the sweep is not.
+
+So this policy is what the rest of the rollout aims at and mostly cannot reach:
+a port that is genuinely closed to everything but the namespaces named below.
+*/ -}}
 {{- if .Values.networkPolicy.enabled }}
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
   name: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+  labels:
+    app: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
 spec:
   podSelector:
     matchLabels:
       app: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
-  # Ingress only. Egress is deliberately unrestricted: this instance opens no
-  # outbound connection of its own (no replication, no cluster bus), so an
-  # egress rule here would constrain nothing while making the object look
-  # stricter than it is.
   policyTypes:
     - Ingress
   ingress:
-    # One rule with a list of sources. Note the shape: an empty "from" would
-    # allow EVERYTHING, so the namespaces are always spelled out - the release's
-    # own namespace first, then whatever networkPolicy.allowedNamespaces adds.
+    {{- /*
+    One rule with a list of sources. Note the shape: an empty "from" would allow
+    EVERYTHING, so the namespaces are always spelled out - the release's own
+    namespace first, then whatever networkPolicy.allowedNamespaces adds. An
+    empty "from: []" is worse still, because it allows everything while reading
+    as a restriction; ci/run-networkpolicy-test.sh rejects that form outright.
+    */}}
     - from:
         - namespaceSelector:
             matchLabels:
-              # Set by Kubernetes itself on every namespace (>= 1.21), so this
-              # needs no labelling work on the target namespaces.
+              {{- /*
+              Set by Kubernetes itself on every namespace (>= 1.21), so this
+              needs no labelling work on the target namespaces.
+              */}}
               kubernetes.io/metadata.name: {{ .Release.Namespace }}
         {{- range .Values.networkPolicy.allowedNamespaces }}
         - namespaceSelector: