fix AiTokenLimiterPlugin appendResponse

[HY-love-sleep]

Question:

In the appendResponse method,
Processing ByteBuffer in chunks leads to the first ByteBuffer having a gzip response header, which is correctly decompressed. Subsequent ByteBuffers are intermediate segments in the compressed stream and no longer contain a header. When taken out separately and decompressed using GZIPInputStream, they cannot identify the beginning and will report an error when constructing the stream or reading data. If subsequent chunks fail to decompress, the original compressed bytes will be written to BodyWriter unchanged. What accumulates in BodyWriter is a garbled binary stream rather than decompressed text. This leads to inaccurate token statistics.

Solution:

By decompressing across chunks in a streaming manner, memory consumption is reduced while gzip data is correctly processed and token counts are accurately tallied.

[Aias00]

问题：

在appendResponse中

逐块处理ByteBuffer， 导致第一个ByteBuffer拥有gzip响应头， 正确解压 ， 后续ByteBuffer是压缩流中的中间片段，它们不再包含 header，单独拿出来做 GZIPInputStream 解压时，根本无法识别开头，直接就会在构造流或者读数据时报错。后续块一旦解压失败， 会把原始的压缩字节原封不动地写入 BodyWriter，这样累积到 BodyWriter 里的，是乱码的二进制流，而不是解压后的文本。导致token统计不准确。

解决：

通过流式跨块解压， 降低内存消耗同时， 正确处理gizp数据， 统计token 数量

using english，pls

[HY-love-sleep]

问题：
在appendResponse中
逐块处理ByteBuffer， 导致第一个ByteBuffer拥有gzip响应头， 正确解压 ， 后续ByteBuffer是压缩流中的中间片段，它们不再包含 header，单独拿出来做 GZIPInputStream 解压时，根本无法识别开头，直接就会在构造流或者读数据时报错。后续块一旦解压失败， 会把原始的压缩字节原封不动地写入 BodyWriter，这样累积到 BodyWriter 里的，是乱码的二进制流，而不是解压后的文本。导致token统计不准确。
解决：
通过流式跨块解压， 降低内存消耗同时， 正确处理gizp数据， 统计token 数量

using english，pls

done

[Aias00]

LGTM