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

apache-tika/templates/NOTES.txt

@@ -58,3 +58,57 @@ THE JVM ONLY GETS A QUARTER OF THE MEMORY LIMIT
   cheap regardless; the heap is what matters for parsers that have to build a
   whole document in memory, and for OCR.
 {{- end }}
+{{- if .Values.networkPolicy.enabled }}
+
+NETWORKPOLICY IS ACTIVE — WHAT IT CAPS, AND WHAT IT DOES NOT
+  {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy selects this workload's pods.
+  Inbound: TCP 9998 only. Outbound: DNS{{ with .Values.networkPolicy.egress }}{{ with .extraPorts }} plus TCP {{ join ", " . }}{{ end }}{{ end }} — Tika is handed documents and
+  fetches nothing.
+
+  THIS CHART HAS NO INGRESS AND ITS CONSUMERS ARE OTHER PODS. While
+  networkPolicy.probeSources is empty the 9998 rule has no source selector, so
+  any pod in the cluster — including a paperless-ngx release in another
+  namespace — reaches it. Narrowing probeSources restricts that rule, and the
+  consumers' namespaces must then be listed in networkPolicy.allowedNamespaces
+  in the same change, or document extraction stops with a connection error on
+  the paperless side and nothing at all on this one.
+
+  Three limits belong in the same breath, because none of them is visible in
+  the object itself:
+
+  - EGRESS IS BY PORT, NEVER BY DESTINATION. A NetworkPolicy matches CIDRs and
+    selectors and cannot express a hostname, so every egress rule permits its
+    port to ANY address. That is a limit of the object, not a shortcut — this
+    cluster's CNI (Canal: Flannel plus Calico) has no FQDN rule either. An
+    outbound port the chart does not know about is BLOCKED: add it to
+    networkPolicy.egress.extraPorts, and expect to find out through an
+    application-level connection error rather than through this object.
+{{- if .Values.networkPolicy.probeSources }}
+  - THE PROBE PATH IS RESTRICTED in this release, because
+    networkPolicy.probeSources is set to
+      {{ join ", " .Values.networkPolicy.probeSources }}
+    Probes come from the IP of the WORKER NODE running the pod. If none of those
+    CIDRs covers the node this pod lands on, the kubelet's probes are dropped
+    and THE POD NEVER BECOMES READY — the rollout then times out and the symptom
+    looks like a broken application. Compare
+
+      kubectl -n {{ .Release.Namespace }} describe pod -l app={{ .Release.Name }}-{{ .Chart.Name }}-deployment
+
+    against `kubectl get node -o wide`.
+{{- else }}
+  - THE PROBED PORT IS OPEN INSIDE THE CLUSTER. networkPolicy.probeSources is
+    empty, so that rule carries no source selector at all and any pod the CNI
+    routes to can reach it. Not from the internet — but this is NOT pod-level
+    isolation. Narrowing it means listing the worker node IPs in
+    networkPolicy.probeSources, because the kubelet probes from the node's own
+    address and the chart cannot know it; a wrong guess there leaves the pod
+    permanently un-Ready.
+{{- end }}
+  - IT IS ONLY A BOUNDARY WHERE THE CNI ENFORCES POLICIES. Where it does not,
+    this object is accepted and filters nothing, so everything reads as
+    configured while nothing is filtered. `kubectl -n {{ .Release.Namespace }} get networkpolicy`
+    shows the object exists; only a connection attempt from an unrelated
+    namespace shows that it bites.
+
+  Switch it off with networkPolicy.enabled: false.
+{{- end }}

apache-tika/templates/apache-tika.networkpolicy.yaml

@@ -0,0 +1,149 @@
+{{- /*
+NetworkPolicy for apache-tika (Gitea #5).
+
+Apache Tika here is a cluster-internal service: the chart creates no Ingress at
+all, and its only consumers are other pods - paperless-ngx points at
+http://<service>.<namespace>.svc.cluster.local for text extraction.
+
+THAT MAKES THE SOURCE QUESTION THE INTERESTING ONE, AND IT HAS AN AWKWARD
+ANSWER. 9998 is the port all three probes address, so it cannot be restricted
+by source without the worker node's IP - and this chart's consumers live in
+OTHER namespaces (paperless-cmk, paperless-jk, paperless-tb in this cluster).
+So an operator who narrows probeSources has to list those namespaces in
+allowedNamespaces in the same breath, or every document extraction stops. That
+is written into values.yaml and NOTES.txt rather than left to be discovered.
+
+Egress is DNS only. Tika extracts text from documents it is handed; it fetches
+nothing, and a text extractor that can reach the internet is a worse thing to
+hand an untrusted document to.
+
+WHAT THIS OBJECT IS: a ceiling on reachability, not an authentication layer.
+Only the ports declared below are reachable at all - whatever else the process
+binds, now or after the next app update, is blocked without anyone having to
+notice it exists.
+
+WHAT IT IS NOT:
+  - EGRESS IS COARSE. A NetworkPolicy matches CIDRs and selectors and NEVER
+    hostnames, so "only to the database host" cannot be expressed at all. This
+    cluster's CNI is Canal (Flannel plus Calico for policy) and has no FQDN
+    rule; Calico's GlobalNetworkSet could express one but would bind this chart
+    to Calico, the same argument that kept implementation-specific objects out
+    of the Gateway-API sweep (#114). Each egress rule therefore permits its
+    PORT to any destination.
+  - NOT A BOUNDARY WHERE THE CNI DOES NOT ENFORCE ONE. An unenforced policy is
+    accepted by the API server and filters nothing, so everything reads as
+    configured while nothing is filtered.
+  - THE REASONING IS IN TEMPLATE COMMENTS, not in "#" comments: those are part
+    of the rendered object, travel into the cluster and appear in every release
+    diff. ci/run-networkpolicy-test.sh fails on a rendered "#".
+
+THE PORT NUMBERS BELOW ARE POD PORTS, NEVER NODEPORTS. A NetworkPolicy is
+evaluated at the pod's network interface, after kube-proxy has already
+translated a NodePort to the targetPort, so a NodePort number here would match
+nothing while looking strict - and, being the only rule for that port, would
+block every inbound connection instead. ci/run-networkpolicy-test.sh asserts
+every port here against the containerPorts of the pod spec this policy
+selects.
+*/ -}}
+{{- if .Values.networkPolicy.enabled }}
+{{- $np := .Values.networkPolicy }}
+{{- $ns := .Release.Namespace }}
+{{- $probeSources := $np.probeSources | default list }}
+{{- $allowedNs := $np.allowedNamespaces | default list }}
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+  labels:
+    app: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+spec:
+  {{- /*
+  Selects the Deployment's pods. ci/run-networkpolicy-test.sh fails if
+  this matches no pod spec of the same render - which is the mistake that
+  would otherwise leave a policy in the namespace filtering nothing, and
+  its usual cause is a label renamed in the workload template.
+  */}}
+  podSelector:
+    matchLabels:
+      app: {{ .Release.Name }}-{{ .Chart.Name }}-deployment
+  policyTypes:
+    - Ingress
+    {{- /*
+    Egress is listed because there is something real to restrict: Tika extracts
+    text from documents it is handed and fetches nothing of its own, so DNS is the
+    only rule. A text extractor that can reach the internet is a worse thing to
+    hand an untrusted document to.
+    */}}
+    - Egress
+  ingress:
+    {{- /*
+    9998 - the only port this pod declares, the one the Service forwards 80 to, and
+    the one all three probes address. The probe path.
+    */}}
+    - ports:
+        - protocol: TCP
+          port: 9998
+      {{- if $probeSources }}
+      {{- /*
+      RESTRICTED, because the operator supplied probeSources. The kubelet's probes
+      come from the IP of the WORKER NODE running the pod, so that address has to be
+      in the list or the pod never becomes Ready - and a pod that is never Ready
+      reads as a broken application rather than as a policy.
+
+      NO ingress controller is added here, because this chart renders no Ingress: its
+      consumers are other pods, and they have to be named in allowedNamespaces.
+      */}}
+      from:
+        - namespaceSelector:
+            matchLabels:
+              {{- /*
+              Set by Kubernetes itself on every namespace (>= 1.21), so this needs no
+              labelling work on a namespace this chart does not own.
+              */}}
+              kubernetes.io/metadata.name: {{ $ns }}
+        {{- range $allowedNs }}
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: {{ . | quote }}
+        {{- end }}
+        {{- range $probeSources }}
+        - ipBlock:
+            cidr: {{ . | quote }}
+        {{- end }}
+      {{- else }}
+      {{- /*
+      NO "from" SELECTOR, WHICH MEANS OPEN - deliberately, and only inside the
+      cluster, because this port carries no NodePort. The alternative was to guess
+      the worker node CIDRs, and a wrong guess blocks every kubelet probe: the pod
+      stays un-Ready, the rollout times out, and the cause looks like the
+      application. An empty "from: []" would be worse than either - it allows
+      everything too, but while reading as a restriction. Narrow it with
+      networkPolicy.probeSources.
+      */}}
+      {{- end }}
+  egress:
+    {{- /*
+    DNS, unconditionally. There is no value to switch this off, and that is
+    deliberate: a knob whose only other setting breaks every name lookup in
+    the pod is a trap and not a feature.
+    */}}
+    - ports:
+        - protocol: UDP
+          port: 53
+        - protocol: TCP
+          port: 53
+    {{- with $np.egress }}
+    {{- with .extraPorts }}
+    {{- /*
+    Ports only, to any destination - see the header. This is the operator's
+    escape hatch from the egress cap, and the only alternative to switching
+    the whole policy off.
+    */}}
+    - ports:
+        {{- range . }}
+        - protocol: TCP
+          port: {{ int . }}
+        {{- end }}
+    {{- end }}
+    {{- end }}
+{{- end }}