feat!: NetworkPolicy in six more charts, on by default

bentopdf, apache-tika, gotenberg, rss-bridge, searxng, ytdlp-web-player. One
major each, networkPolicy.enabled defaults to true.

Three of them differ from the simple case in ways worth naming:

GOTENBERG gets DNS-only egress as a deliberate, documented trade. It drives a
headless Chromium, and 3000 is its probe port - so it is reachable from the
whole cluster by default, and an egress rule for 80/443 would turn a service
anyone can POST to into a way of fetching arbitrary URLs. The price is the
remote-asset half of HTML conversion: inline content converts, images the page
would have fetched silently do not. That degrades a PDF instead of failing a
pod, so nothing alerts on it, which is why it is in the template header, in
values.yaml and in NOTES.txt, with extraPorts: [80, 443] named as the knowing
opt-in.

RSS-BRIDGE, SEARXNG and YTDLP-WEB-PLAYER get the open internet on their web
ports, because reaching other people's servers IS the application and this
object cannot name a host. Said plainly in each, so none of them reads
stricter than it is. What the cap still buys is real: no other outbound port,
so a compromised pod reaches no database, no mail server and no SSH anywhere.

APACHE-TIKA and GOTENBERG render no Ingress - their consumers are other pods,
in other namespaces here - so neither gets an ingressController value and both
say in NOTES.txt that narrowing probeSources means listing the consumers'
namespaces in allowedNamespaces in the same change, or extraction and
conversion stop.

YTDLP-WEB-PLAYER names the gap this convention has: its oauth2-proxy subchart
renders its own Deployment with its own labels and ships no policy, so with the
proxy enabled the pod that actually faces the Ingress is unrestricted in both
directions. Nothing in this chart can change that - an upstream chart is
consumed as it comes - so it is written down instead.

ci/outline/test-values.yaml gains egress.extraPorts: [5556]. The CI dex runs
there rather than on 443, and Outline fetches the discovery document at boot -
so this is the chart's documented escape hatch used for exactly the case it was
written for, and the one place in the repo where the cap's upgrade risk is
actually exercised.

Part of #5

ytdlp-web-player/values.yaml

@@ -455,3 +455,86 @@ oauth2-proxy:
   # it is spelled out here because switching it on looks like an upgrade.
   alphaConfig:
     enabled: false
+
+# ---------------------------------------------------------------------------
+# NetworkPolicy (Gitea #5). On by default. The reference implementation with
+# the full reasoning is template-chart; the convention is in README, "Chart
+# style guidelines", and the operator's view on this chart's wiki page.
+# ---------------------------------------------------------------------------
+networkPolicy:
+  # WHAT THIS POLICY ALLOWS: inbound 5000 only, and outbound DNS plus TCP 80
+  # and 443 to ANY destination - fetching media is the application, and this
+  # object cannot name a host.
+  #
+  # WHAT IT DOES NOT COVER: THE OAUTH2-PROXY SUBCHART'S PODS. This policy
+  # selects this chart's own workload by its app label. The subchart renders
+  # its own Deployment with its own labels and ships no policy, so with the
+  # proxy enabled the pod that actually faces the Ingress is unrestricted in
+  # both directions. That is a gap in the convention, not a choice of this
+  # chart: an upstream chart is consumed as it comes (README, "Chart
+  # dependencies"). Do not read "this chart has a NetworkPolicy" as "this
+  # release is covered".
+  #
+  # Inbound 5000 is not restricted by source in the default (probe port), and a
+  # policy is only a boundary where the CNI enforces one.
+  enabled: true
+  # Namespaces whose pods may reach this workload, in addition to the release's
+  # own namespace, which is always allowed. Empty means: own namespace only.
+  #
+  # Matched on the "kubernetes.io/metadata.name" label Kubernetes sets on every
+  # namespace itself, so no labelling work is needed on a namespace this chart
+  # does not own - and no typo protection either: a name that does not exist
+  # matches nothing and is silently ineffective. Note the granularity: an entry
+  # opens the port to EVERY pod in that namespace.
+  allowedNamespaces: []
+  # Source CIDRs allowed to reach the port named "http" (5000), which all three probes address.
+  #
+  # EMPTY MEANS OPEN, NOT BLOCKED. With no entry that rule is rendered WITHOUT a
+  # "from" selector, so the port is reachable from anywhere the CNI routes to -
+  # inside the cluster, since it carries no NodePort.
+  #
+  # That is the deliberate choice between two bad defaults. The kubelet's probes
+  # originate from the IP of the WORKER NODE running the pod, an address this
+  # chart cannot know and must not guess: a CIDR that excludes the real node
+  # blocks every probe, the pod never becomes Ready, the rollout times out, and
+  # the symptom reads as a broken application rather than as a policy.
+  #
+  # Narrow it by listing the worker node IPs (e.g. ["10.0.1.11/32"]) - and mind
+  # the companion trap: once this list is non-empty the rule IS restricted, so
+  # everything else that needs the port has to be in it. The chart adds the own
+  # namespace, the ingressController below and allowedNamespaces to the same rule for exactly that reason.
+  probeSources: []
+  # The ingress controller allowed to reach the routed port once probeSources
+  # restricts it. Rendered only while ingress.enabled or httpRoute.enabled is true, and only in
+  # the restricted branch - with the default (open) rule the controller reaches
+  # the port anyway. The two keys become ONE "from" entry and are therefore an
+  # AND: pods carrying podLabels IN namespace. That is the point of having them
+  # at all - the controller's namespace in allowedNamespaces would open the port
+  # to every pod in kube-system.
+  #
+  # MEASURED ON THIS CLUSTER, NOT ASSUMED (2026-10-14): ingress-nginx is gone,
+  # the only IngressClass is "traefik" and it is the default, and the controller
+  # is the DaemonSet rke2-traefik in kube-system. The same Traefik serves the
+  # Gateway API here, so this one source covers the Ingress and the HTTPRoute
+  # path alike. A policy written against the wrong controller is accepted, looks
+  # strict, and silently blocks all web traffic - and ingress.className says
+  # nothing about it, because a class names an implementation, not the pods the
+  # traffic comes from.
+  ingressController:
+    namespace: kube-system
+    podLabels:
+      app.kubernetes.io/name: rke2-traefik
+  egress:
+    # Additional outbound TCP ports. DNS (UDP and TCP 53) is always allowed and
+    # has no switch - a knob whose only other setting breaks every name lookup
+    # in the pod is a trap, not a feature.
+    #
+    # PORTS, NOT DESTINATIONS, and that is a limit of the object rather than
+    # laziness: a NetworkPolicy matches CIDRs and selectors and never hostnames,
+    # so "only to the database host" cannot be written at all. Each entry
+    # permits its port to ANY destination. What the cap still buys is real: a
+    # compromised pod cannot open arbitrary outbound connections.
+    #
+    # 80 and 443 are already allowed. Add a port only for a source that serves
+    # media elsewhere.
+    extraPorts: []