feat(template-chart)!: ambientMesh becomes an object, and the CI exception gets a pinned expectation

Gitea #143, maintainer's instruction. Both numbers this switch renders are
ISTIO CONSTANTS rather than standards, and a value with a documented default
is the better home for a vendor constant than a template literal: an operator
can correct it when Istio changes the number, without waiting for a chart
release.

    networkPolicy:
      ingress:
        ambientMesh:
          enabled: false
          port: 15008
          redirectedProbeSources:
            - 169.254.7.127/32

One object under one switch, so the coupling argument survives the change
instead of being undermined by it - two separate values could drift apart,
which is the thing this design exists to prevent. redirectedProbeSources is a
LIST because a dual-stack cluster needs BOTH of Istio's addresses at once, not
one of two; that is a nameable case rather than speculation, so it does not
contradict reason 4 of the issue. Istio's IPv6 counterpart is documented as the
dual-stack addition, with the reason it is absent today unchanged: SingleStack
IPv4, and an ipBlock of the wrong family is accepted and matches nothing.

Named redirectedProbeSources, not probeSources, because the confusion risk with
networkPolicy.probeSources one level up is larger than the ingress/
ingressController one: that value holds YOUR worker node CIDRs, is empty by
default and means OPEN when empty; this one holds ISTIO's rewrite address and
ships filled, because unlike the node IPs it is a constant the chart can know.
The distinction is written where both appear.

PROVENANCE, which the previous round explained the coupling of but never
attributed. 15008 is Istio's HBONE port - not IANA-registered for this, not
prescribed by any protocol, unknown to Kubernetes. 169.254.7.127 is link-local
(169.254.0.0/16, RFC 3927, never routed - the range one picks vendor magic out
of); Istio's IPv6 counterpart fd16:9254:7127:1337:ffff:ffff:ffff:ffff carries
the same digits plus 1337, which is what vendor constants look like; and
Kubernetes knows the address in neither the NetworkPolicy API nor the kubelet -
only Istio's data plane rewrites the probe source onto it. Both read for
ztunnel 1.30.6. If either changes, the failure is SILENT: a pod unreachable in
the mesh, or probes dropped where probeSources is non-empty, which is nowhere
today.

NULL-SAFE, per #99 and because #136 shipped this exact defect one value away
(its NOTES.txt branch dereferenced .networkPolicy.egress directly): every read
goes through a fallback reproducing the chart's own declared defaults, so a
deleted object or one carrying only "enabled: true" renders the defaults rather
than failing. Clearing the probe-source list restores the constant instead of
removing the ipBlock, deliberately - the halves are not separable, and
enabled: false is how you open nothing.

THE CONSEQUENCE, and it is the point of the CI half. With the port
configurable, the exception can no longer be checked against the rendered
value: "whatever the value says" is design A's hole wearing design C's name,
and a mistyped port would pass by sitting in the configurable field. So the
expectation is PINNED IN THE TEST - AMBIENT_PORT and AMBIENT_CIDR - and
assertion 7 now checks two things instead of one: that the render at chart
defaults produces exactly that port and that ipBlock, and that every chart's
values.yaml DECLARES the same defaults, read back through ci/yaml2json rather
than by regex. A chart that drifts is red. Changing an Istio constant means
touching 30 values files AND the pinned lines, and the pinned lines are what
force someone to look.

That block is therefore also the single place saying what we hold Istio's
numbers to be, so it carries the provenance too. The renders set only
enabled=true and never a port override, on purpose: the pin is a statement
about the defaults we ship, not about what a release may choose - an operator
overriding a value is outside this test's reach, as for every value here.

The declared-defaults check is conditional on the chart offering probeSources,
like the inseparability check and assertion 4: the five charts whose probe rule
is never source-restricted render no ipBlock, so for them the key must be
ABSENT - a value reaching no rule reads as a control that does nothing - and
that absence is asserted rather than tolerated. Their schemas drop it too.

No version change: nothing of this is published, the switch stays additive with
its default off, and the render at defaults is byte-identical - re-diffed per
chart against origin/main, not assumed.

template-chart/values.yaml

@@ -283,50 +283,111 @@ networkPolicy:
   #                                  pods. A SIBLING of this block and NO PART
   #                                  OF IT, despite the name.
   ingress:
-    # Opens the pod for Istio's ambient mesh. OFF by default, and additive:
-    # with it off this chart renders byte for byte as it did before the value
-    # existed.
+    # Opens the pod for Istio's ambient mesh. OFF by default, and additive: with
+    # it off this chart renders byte for byte as it did before the value existed.
     #
     # WHAT IT RENDERS, and the two halves are the point:
     #
-    #   1. 15008/TCP inbound - ztunnel's HBONE tunnel. Every inbound mesh
-    #      connection arrives on it, and Istio's documentation is explicit that
-    #      ambient "does not and will never bypass Kubernetes NetworkPolicy
-    #      enforcement". Without this port a pod whose namespace has joined the
-    #      mesh is unreachable.
-    #   2. 169.254.7.127/32 as an additional probe source - but ONLY where
-    #      probeSources is non-empty, because only then does the rule have a
-    #      "from" list at all. Inside the mesh the kubelet's probes are
-    #      redirected and no longer come from the worker node's address.
+    #   1. The HBONE port inbound (default 15008/TCP) - ztunnel's tunnel. Every
+    #      inbound mesh connection arrives on it, and Istio's documentation is
+    #      explicit that ambient "does not and will never bypass Kubernetes
+    #      NetworkPolicy enforcement". Without this port a pod whose namespace
+    #      has joined the mesh is unreachable.
+    #   2. The redirected probe source (default 169.254.7.127/32) - but ONLY
+    #      where networkPolicy.probeSources is non-empty, because only then does
+    #      the rule have a "from" list at all. Inside the mesh the kubelet's
+    #      probes are redirected and no longer come from the worker node's
+    #      address.
     #
     # WHY ONE SWITCH AND NOT TWO. Point 2 is the one nobody thinks of. An
     # operator who adds "15008" to a port list by hand writes a policy that
     # passes review, and the first time probeSources is narrowed every probe is
     # dropped: the pod never becomes Ready and the symptom reads as a broken
-    # application rather than as a policy. A switch whose halves can only be
-    # had together cannot be set halfway - which is why this is a named
-    # intention and not a free port list.
+    # application rather than as a policy. A switch whose halves can only be had
+    # together cannot be set halfway - which is why the two live in ONE object
+    # under one "enabled", and not as separate values that can drift apart.
     #
-    # TWO THINGS IT DOES NOT PROVE, and they belong next to the value rather
-    # than in a commit message:
+    # BOTH NUMBERS BELOW ARE ISTIO CONSTANTS, NOT STANDARDS, and they are values
+    # rather than template literals for exactly that reason: a vendor constant
+    # can change, and an operator should be able to correct it without waiting
+    # for a chart release. Their provenance is written on each one.
     #
-    #   - That 15008 alone is enough. That comes from Istio's documentation.
-    #     Measured on this cluster is only which listeners ztunnel opens
-    #     ([::]:15008 inbound, plus its own admin and stats ports). Provable at
-    #     the first namespace that joins the mesh; none carries
-    #     istio.io/dataplane-mode yet.
-    #   - That the probe-source half works. probeSources is empty in every
-    #     chart here, so no release reaches that branch. CI proves its render,
-    #     not its effect.
-    #
-    # If the policy restricts sources, note that 15008 is restricted with them:
-    # the port joins the rule that carries the probe port, so it is reachable
-    # from that rule's peers only. Whether ztunnel needs a peer of its own is
-    # open - it runs with its own pod IPs in istio-system (measured: no
-    # hostNetwork on the DaemonSet, Istio 1.30.6), so if one turns out to be
-    # needed it is expressible as a namespaceSelector plus podSelector and does
-    # not need an unknowable node-IP CIDR.
-    ambientMesh: false
+    # DELETING THIS OBJECT IS SAFE. Every read falls back to the defaults
+    # declared here (#99), so "ambientMesh: null", or an object carrying only
+    # "enabled: true", renders the documented defaults instead of failing.
+    ambientMesh:
+      # The switch. Everything else in this object is inert while it is false,
+      # and the chart renders exactly as it did before the object existed.
+      enabled: false
+
+      # ISTIO'S HBONE PORT. A constant Istio chose, not a standard: it is not
+      # registered with IANA for this, no protocol prescribes it, and Kubernetes
+      # knows nothing about it. Read for ztunnel 1.30.6 (measured on this
+      # cluster: ztunnel opens [::]:15008 as its inbound listener).
+      #
+      # If Istio changes it, a pod in the mesh simply cannot be reached. Change
+      # it here in all 30 charts AND in the pinned expectation inside
+      # ci/run-networkpolicy-test.sh - the test is deliberately the thing that
+      # forces someone to look, because the exception it grants this port is
+      # pinned to the number IT knows and not to whatever this value says. A
+      # value-driven exception would let a mistyped port through, which is the
+      # hole design A of #143 was rejected for.
+      #
+      # NOT MEASURED: that this port ALONE suffices comes from Istio's
+      # documentation. Measured here is only which listeners ztunnel opens.
+      # Provable at the first namespace to join the mesh; none carries
+      # istio.io/dataplane-mode yet.
+      port: 15008
+
+      # SOURCES THE KUBELET'S PROBES ARRIVE FROM ONCE ISTIO HAS REDIRECTED THEM.
+      #
+      # NOT THE SAME VALUE AS networkPolicy.probeSources one level up, and the
+      # two are easy to confuse, so:
+      #
+      #   networkPolicy.probeSources
+      #       YOUR worker node CIDRs. Empty by default, and empty means the
+      #       probe rule is OPEN. The chart cannot know these addresses.
+      #   networkPolicy.ingress.ambientMesh.redirectedProbeSources
+      #       ISTIO's rewrite address. Shipped filled, because unlike the node
+      #       IPs it is a constant the chart CAN know. Only rendered where the
+      #       rule above is restricted, i.e. where probeSources is non-empty.
+      #
+      # WHERE 169.254.7.127 COMES FROM, so it is recognisable as vendor magic
+      # rather than as protocol:
+      #
+      #   - It is LINK-LOCAL, 169.254.0.0/16 (RFC 3927): a range reserved for
+      #     node-local use that is never routed - exactly the range one picks a
+      #     vendor's magic address out of.
+      #   - Istio's IPv6 counterpart gives it away:
+      #     fd16:9254:7127:1337:ffff:ffff:ffff:ffff carries the SAME DIGITS
+      #     (9254:7127 is 169.254.7.127) plus 1337. Numbers built that way are
+      #     vendor constants, not protocols.
+      #   - KUBERNETES DOES NOT KNOW THIS ADDRESS. Neither the NetworkPolicy API
+      #     nor the kubelet has any notion of it; only Istio's own data plane
+      #     rewrites the probe source onto it.
+      #
+      # Read for ztunnel 1.30.6. IF ISTIO CHANGES IT, THE FAILURE IS SILENT:
+      # probes would be dropped, and only where probeSources is non-empty - which
+      # is nowhere in this repository today - so nothing here and nothing in
+      # Kubernetes would report it. What to re-check then: the address Istio's
+      # release notes name for probe redirection, and this list in all 30 charts
+      # plus the pinned expectation in ci/run-networkpolicy-test.sh.
+      #
+      # A LIST, not a string, and this is the one case where that does not
+      # contradict "a constant, not a configuration": on a DUAL-STACK cluster
+      # BOTH entries are needed at the same time, not one of two. This cluster is
+      # SingleStack IPv4, so the IPv6 counterpart is left out - an ipBlock of the
+      # wrong family is accepted by the API server and matches nothing. Add it
+      # ALONGSIDE, never instead, if the cluster gains IPv6.
+      #
+      # Clearing this list restores the default rather than removing the
+      # ipBlock, deliberately: the two halves of this switch are not separable.
+      # To not open the port at all, set enabled: false.
+      #
+      # UNPROVEN IN OPERATION: probeSources is empty in every chart here, so no
+      # release reaches this branch. CI proves the render, not the effect.
+      redirectedProbeSources:
+        - 169.254.7.127/32
 
   egress:
     # Additional outbound TCP ports. DNS (UDP and TCP 53) is always allowed and