Fix stale exception assertion in DeserializingConnectionCallbackTest

[reiabreu]

Summary

DeserializingConnectionCallbackTest.testJavaFallbackNegativeLengthDroppedAndBatchContinues fails on current master (e.g. run #9080, and on plain master runs), breaking the test (25, Client, ...) CI job.

Root cause

• Drop malformed tuple payloads instead of killing the receiving worker #9076 added the test, which corrupts the java-serialization length prefix to all-0xFF and expected SerializableSerializer.read() to reach new byte[len] and throw NegativeArraySizeException.
• The very next commit, Harden the java serialization fallback bridge with a JEP-290 serial filter #9075, added a guard to SerializableSerializer.read() that rejects a negative length with a KryoException before the array is allocated. The dead NegativeArraySizeException path can no longer be hit, but the test assertion was not updated.

Change

• Assert KryoException (the exception the hardened path now throws) instead of NegativeArraySizeException.
• Fix the now-stale comment describing the old allocate-then-fail behavior.

KryoException is already a tolerated deserialization-failure/drop reason (the sibling testTruncatedKryoPayloadDroppedAndBatchContinues asserts it and reuses the same assertBatchDeliversOnlyValidMessages helper), so the batch-continues assertion is unaffected.

Verification

Ran the class locally on JDK 25: Tests run: 10, Failures: 0, Errors: 0 — including the previously failing test.

🤖 Generated with Claude Code