[BUG] Malformed cluster token server frames may trigger excessive allocation or corrupt request decoding

Issue Description

Type: bug report

Describe what happened

The cluster token server decoders trust length and count fields received from the network before fully validating them. A malformed request can declare an oversized Ping namespace length or an invalid ParamFlow parameter count/string length. This may cause excessive allocation, out-of-bounds reads, or leave unread bytes in the current frame.

Describe what you expected to happen

All externally supplied lengths and counts should be validated before allocation or iteration. A structurally invalid frame should be rejected and its connection closed so that no residual bytes can affect a later request.

How to reproduce it (as minimally and precisely as possible)

1. Start the default cluster token server.
2. Send a Ping frame whose declared namespace length differs from the bytes remaining, or a ParamFlow frame with a negative/impossible count or string length.
3. Observe invalid allocation/read behavior or incomplete consumption of the malformed frame.

Tell us your environment

Sentinel 1.8 branch, default Netty cluster token server.

Anything else we need to know?

PR #3572 adds strict frame validation, connection-close handling, and regression tests covering valid requests, malformed/truncated lengths, invalid ParamFlow fields, trailing bytes, and oversized frames.