docs: correct the OOM-arm discharge in RedisStreamCodec — no publish-time guard ships

Folded in from #8145 (closed in favour of carrying it here), addressing review
feedback on #8089 that landed after that PR merged.

The javadoc justified absorbing an OutOfMemoryError by pointing at a
publish-time size guard as the control covering the residual risk, naming
onlineScoring.dropOversizedPayloads. That key does not exist: a repo-wide grep
returns exactly one hit, the sentence itself.

It never shipped. #8060 was merged as the Guice/Dropwizard ordering fix that
made the codec actually receive maxStringLength; the publisher-side drop guard
it originally carried was cut from that PR before merge, under this or any
other name.

That matters more than a stale reference normally would, because of the job
the sentence was doing. The paragraph above it makes the most serious
admission in the design -- under real heap pressure this arm absorbs an OOM
that was a symptom rather than a cause and keeps consuming, masking it -- and
this sentence was its discharge. With no such guard the risk is open, not
delegated, and someone auditing the decision later would go looking for a
control that was never built.

Wording as suggested in review. Comment-only: the OOM-absorbing call itself is
unchanged and not in question.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: thiagohora

apps/opik-backend/src/main/java/com/comet/opik/infrastructure/redis/RedisStreamCodec.java

@@ -164,8 +164,9 @@ public static Codec faultTolerant(Codec delegate) {
      * a cause, and keep consuming — masking it. The recovery measured above is single-threaded and
      * proves the decode path, not a loaded service; an allocation large enough to fail can still starve
      * a different thread, which throws where nothing catches it. The counter to that is a size guard at
-     * publish time, which is what {@code onlineScoring.dropOversizedPayloads} does, not anything this
-     * codec can do on read.
+     * publish time. No such guard ships today -- #8060 applied the codec's stream-read limits but added
+     * no publisher-side size check -- so this residual risk is open rather than delegated. It is not
+     * something this codec can address on read.
      * <p>
      * No other {@link Error} is absorbed — a {@link StackOverflowError} still propagates.
      */