docs(rss-bridge): #51 was closed, and the cause was never identified (2.1.1)

PR #124 merged at 12:25 and the maintainer closed #51 one second later, on
the strength of that round's green install-test. Three statements that
merged with #124 are stale as a result, and they are stale in the
direction that matters - they describe a failing test and an open issue:

  - rss-bridge/templates/rss-bridge.httproute.yaml and values.yaml said
    the install-test "fails on the Gitea runner (#51)", in the present
    tense, and values.yaml added "and that test is still red".
  - ci/httproute/rss-bridge.yaml said "#51 is not closed on the strength
    of a colour", which was true when written and is now the opposite of
    what happened.

Replaced with what is actually known, and the emphasis moved to the part
that outlives the colour: the test went green on a render byte-identical
to main, which rules the chart out and leaves the runner - and THE CAUSE
WAS NEVER IDENTIFIED. The diagnostic programme in #51 (docker info for
userns and the dind configuration, the same image in a local k3d without
remapping) was not executed. So a recurrence is a fresh finding rather
than a known quirk, and the overlay comment now says so where whoever
sees the red will be reading.

Also carries the wording change that was already on this branch when
#124 merged: the reproduced green is phrased as "every run of that branch
since" rather than pinned to a count, because each commit recording the
count invalidated it - a third green arrived with the push after "two".

Patch bump, per the rule #40 was argued on: a comment in a chart
directory is still a change to that chart, so it is a patch plus a
publish. No template output changes - the render for the fixture values
is byte-identical to the pre-#124 main, which the tests re-confirm.

ci/httproute/rss-bridge.yaml

@@ -28,9 +28,13 @@
 # in the job. Since that PR's rendered defaults are byte-identical to
 # origin/main, the chart is ruled out as the cause and the runner is the
 # implicated layer - which is where #51 had already placed it. It reproduced
-# on every run of that branch since, so it is not a fluke; but nobody has
+# on every run of that branch since, so it is not a fluke, and #51 was closed
-# identified what changed on the runner, so #51 is not closed on the strength
+# on that round. What was NEVER identified is the cause: nobody established
-# of a colour.
+# what changed on the runner, and the diagnostic programme in that issue
+# (docker info for userns and the dind configuration, the same image in a
+# local k3d without remapping) was not executed. So if this chart's
+# install-test goes red again, that is a fresh finding and not a known quirk -
+# and this comment is the context it should be read against.
 #
 # Either way this overlay stays load-bearing: the install-test installs the
 # INGRESS mode (that is what the fixture sets), so the Gateway mode of this

rss-bridge/Chart.yaml

@@ -5,7 +5,7 @@ icon: https://raw.githubusercontent.com/RSS-Bridge/rss-bridge/master/static/logo
 
 type: application
 
-version: 2.1.0+up2026.09.30
+version: 2.1.1+up2026.09.30
 appVersion: "2026-09-30"
 
 maintainers:

rss-bridge/templates/rss-bridge.httproute.yaml

@@ -2,8 +2,11 @@
 The Gateway-API alternative to rss-bridge.ingress.yaml (Gitea #114), and the
 LAST chart of that sweep: 22 charts carried an Ingress template and 21 an
 HTTPRoute template, and the difference was this one. It was held back because
-its install-test fails on the Gitea runner (#51), not for anything about its
+its install-test had been failing on the Gitea runner (#51), not for anything
-shape.
+about its shape - and that test went green in the very PR that converted it,
+on a render byte-identical to main, which is what ruled the chart out and left
+the runner. #51 was closed on the strength of that round; the cause was never
+identified, so a recurrence is a fresh finding rather than a known quirk.
 
 WHAT THIS RENDERS, AND WHAT IT DELIBERATELY DOES NOT
 

rss-bridge/values.yaml

@@ -272,9 +272,11 @@ ingress:
 # THE GATEWAY-API ALTERNATIVE TO THE INGRESS ABOVE (Gitea #114), and this chart
 # is the LAST of that sweep - 22 charts carried an Ingress template, 21 an
 # HTTPRoute template, and the difference was this one. It was held back because
-# its install-test fails on the Gitea runner (#51), not for anything about its
+# its install-test had been failing on the Gitea runner (#51), not for anything
-# shape, and that test is still red: the failure is a known, bounded
+# about its shape - and that test went green in the very PR that converted it,
-# environment defect and no finding about this mode.
+# on a render byte-identical to main, which ruled the chart out and left the
+# runner. #51 was closed on that round; the cause was never identified, so a
+# recurrence is a fresh finding rather than a known quirk.
 #
 # Off by default, so an existing release is unaffected. Mutually exclusive with
 # ingress.enabled - the render aborts when both are true, naming both value