rss-bridge: app update 2025-06-03 -> 2025-08-05

One step: 2025-08-05 is the immediate successor release, no publication
in between (verified against the project's release list). Tag present on
Docker Hub for amd64 and arm64.

Patch bump, because the changelog review found nothing that touches the
values surface or the chart's behaviour. Checked against the shipped
source of both images rather than against the release notes:

- whitelist.txt format: lib/Configuration.php is byte-identical apart
  from its VERSION constant, so the parsing the chart relies on (trim,
  split on newline, drop empty entries, "*" wildcard) is unchanged.
- the five production bridges: all present, none renamed. Youtube,
  TheHackerNews, ARDMediathek and Reddit are byte-identical; Heise has a
  content-level change only (paywalled heise+ items now carry an
  archive.is link, two more CSS selectors stripped). The three bridges
  removed upstream - Askfm, DansTonChat, FirstLookMediaTech - are none
  of ours.
- RSSBRIDGE_* environment mapping: same file, therefore unchanged.
- write paths: re-derived empirically rather than inferred, because the
  opcache lock file in /tmp appears in no filesystem diff. The new image
  needs exactly the same five, and a control run without /tmp still dies
  with "Unable to create lock file: Read-only file system".
- health endpoint: actions/ is identical, /?action=health intact.
- PHP 8.2.28 -> 8.2.29, nginx and Debian unchanged, so the
  /run/php/php8.2-fpm.sock path the chart mounts still applies. Measured
  fresh-start peak under five concurrent feed fetches: 64.5 MiB on the
  new image against 71.1 MiB on the old one under an identical
  procedure. Requests and limits stay as they are.

The memory comments in values.yaml are refreshed to the image the chart
now ships, and the older 119 MiB figure is labelled as what it was - a
warm container, not a fresh start.

We stay on the dated release tag. The newest release is itself over
twelve months old and the project now pushes latest and commit-based
sha-* tags continuously, but a sha-* tag is not more released than the
release, only newer, and latest is rolling - both conflict with the
repo's convention of reproducible pinned tags.

Fixes #135

rss-bridge/Chart.yaml

@@ -5,8 +5,8 @@ icon: https://raw.githubusercontent.com/RSS-Bridge/rss-bridge/master/static/logo
 
 type: application
 
-version: 1.0.0+up2025.06.03
-appVersion: "2025-06-03"
+version: 1.0.1+up2025.08.05
+appVersion: "2025-08-05"
 
 maintainers:
   - name: jklein

rss-bridge/values.yaml

@@ -140,9 +140,11 @@ rssBridge:
     limitFactor: 3
     requests:
       cpu: 0.1
-      # Measured with the shipped image: about 59 MiB resident while idle and
-      # roughly 89 MiB after serving feeds, so the previous 20Mi request was
-      # a third of what the workload actually occupies around the clock.
+      # Measured with the shipped image: about 21 MiB resident at startup and
+      # roughly 64 MiB after serving feeds, so the 20Mi the original manifest
+      # requested was a third of what the workload occupies around the clock.
+      # (Re-measured on the 2025-08-05 image; the 2025-06-03 image came out
+      # marginally higher at 24 MiB / 71 MiB under the identical procedure.)
       memory: 128Mi
       # The previous manifest requested 2Gi of ephemeral storage - identical to
       # its limit - and thereby reserved two gigabytes of node scheduling
@@ -164,11 +166,12 @@ rssBridge:
       # Set explicitly rather than left to limitFactor x request.
       #
       # memory: the manifest this chart replaces capped the container at
-      # 100Mi, but five concurrent feed fetches were measured peaking at
-      # 119 MiB - the old limit was already below the real peak, and php-fpm
-      # is configured for up to five workers with a 128M PHP memory_limit
-      # each. 512Mi covers the measured peak with room to spare and still
-      # bounds a runaway bridge.
+      # 100Mi, but a warm container serving five concurrent feed fetches was
+      # measured peaking at 119 MiB - the old limit was already below the real
+      # peak. php-fpm is configured for up to five workers with a 128M PHP
+      # memory_limit each, so the theoretical ceiling is far higher still.
+      # 512Mi covers the measured peak with room to spare and still bounds a
+      # runaway bridge.
       memory: 512Mi
       # Unchanged from the previous manifest on purpose: a large cap costs
       # nothing (it reserves no capacity) and guarantees this change cannot