rss-bridge: new chart

Takes over the four loose manifests in cluster-config/rss-bridge/ as a
proper chart, on the current template-chart standard: strict values
schema, null-safe helpers, computed limits, replicas/scaleDown,
checksum/config, NOTES.txt.

Two things deviate from the repo standard on purpose:

- The Ingress models host AND TLS secret name per entry instead of the
  single conventional tls-<release>-<chart>-ingress. The installation
  this replaces has grown three separate certificates, one per host.
  Renaming them would make cert-manager issue three new ones and leave
  each host unreachable until it did - a self-inflicted outage on a
  deployment that has been up for over a year. Entries sharing a secret
  name are grouped into one tls entry, and omitting the name falls back
  to the convention, so consolidating later is a values change.

- Requests and limits are decoupled. The old manifest requested 2Gi of
  ephemeral storage, identical to its limit, reserving two gigabytes for
  a workload measured at 2.2 MB after fetching all five whitelisted
  bridges. The request drops to 64Mi; the limit stays at 2Gi.

Hardening was verified rather than assumed. The image ships no USER and
runs as root by default, but runs fully hardened once its writable paths
are provided: uid/gid 33, readOnlyRootFilesystem, all capabilities
dropped, seccompProfile RuntimeDefault. The writable paths were found by
running the image with a writable rootfs, exercising every bridge and
reading its diff layer - /app/cache, /run, /run/php, /var/lib/nginx.
/tmp did not show up that way, because PHP's opcache creates its lock
file there and unlinks it immediately; it only surfaced when the
hardened container died at startup. Stopping at the first writable path
would have shipped a chart that cannot start.

Probes use the app's own /?action=health, which renders fixed JSON
without touching the cache or any remote site, so neither a scraped site
going down nor an unwritable cache can restart the pod.

Fixes #128

ci/rss-bridge/test-values.yaml

@@ -0,0 +1,24 @@
+# rss-bridge: stateless, no secrets and no infrastructure to stand up, so only
+# the required ingress values are set. The Ingress just has to apply - there is
+# no ingress-nginx/cert-manager in the CI cluster.
+#
+# Two hosts share a TLS secret name and a third has its own, so the install
+# test renders the secret-grouping helper as well. That helper is what keeps
+# the three existing certificates of the takeover installation alive, and it is
+# not exercised by the chart defaults - an install test that never rendered it
+# would not notice if it broke.
+ingress:
+  clusterIssuer: ci
+  hosts:
+    - host: rss-bridge.ci.local
+      tlsSecretName: tls-ci-shared-ingress
+    - host: rssbridge.ci.local
+      tlsSecretName: tls-ci-shared-ingress
+    - host: rss-bridge.ci.example
+      tlsSecretName: tls-ci-second-ingress
+
+# A concrete list rather than the default "*", so the ConfigMap render and the
+# subPath mount are covered by something the app has to parse.
+whitelist:
+  - Youtube
+  - Heise