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
-# identified what changed on the runner, so #51 is not closed on the strength
-# of a colour.
+# on every run of that branch since, so it is not a fluke, and #51 was closed
+# on that round. What was NEVER identified is the cause: nobody established
+# 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