DefaultStreamingDecoder ByteBuf leak when decode() is called after close

[dong0713]

Bug Description

DefaultStreamingDecoder.decode() does not close the input stream when the decoder has already been closed (closed == true). In the Triple HTTP/2 path, DATA frames are wrapped in ByteBufInputStream(content, true) (i.e., releaseOnClose = true), meaning the underlying pooled ByteBuf is released only when InputStream.close() is called. If a late DATA frame arrives asynchronously (via executor.execute() in AbstractServerTransportListener.onData()) after the decoder has started closing, the ByteBuf is never released, causing a leak.

Symmetry with #16389 / #16391

This is the exact same bug pattern as #16389, which was fixed by #16391 for LengthFieldStreamingDecoder. The fix in #16391 added inputStream.close() in the decode() method when the decoder is closing or closed. DefaultStreamingDecoder has the same pattern but was not included in that fix:

• LengthFieldStreamingDecoder (gRPC path): fixed in [ISSUE #16389] Close late input after streaming decoder shutdown #16391 ✅
• DefaultStreamingDecoder (non-gRPC path): still leaks ❌

Steps to Reproduce

1. Create a DefaultStreamingDecoder instance
2. Call onStreamClosed() to mark the decoder as closed
3. Call decode(inputStream) with any input stream
4. The input stream is never closed, and any wrapped ByteBuf is leaked

Impact

ByteBuf memory leak in the non-gRPC Triple HTTP/2 streaming path when late DATA frames arrive after the decoder has been closed. Under sustained traffic with connection churn, leaked ByteBufs accumulate and can eventually trigger Netty's ResourceLeakDetector warnings or cause OutOfMemoryError.

Suggested Fix

Mirror the #16391 fix: close the input stream in decode() when closed == true, propagating close failures as DecodeException.