[Bug] Validate topK in Lite group info queries

Runtime platform environment

Windows, local broker unit tests; no running cluster is required for the regression test.

RocketMQ version

develop at ff8f6f74c560e391261ccd716707c6d20422e253 (5.5.1).

JDK Version

Amazon Corretto 8u482; Maven 3.9.11.

Describe the Bug

LiteManagerProcessor.getLiteGroupInfo forwards the request's topK directly to the lag calculators when liteTopic is absent or empty. GetLiteGroupInfoRequestHeader.checkFields() does not validate it.

LiteConsumerLagCalculator.getLagCountTopK uses topK as the initial capacity of a PriorityQueue. Zero and negative values are invalid constructor arguments. Large positive values also control the initial backing-array allocation without a server-side bound.

Steps to Reproduce

1. Use an existing Lite consumer group bound to a parent topic.
2. Send GET_LITE_GROUP_INFO with that group, no specific liteTopic, and topK=0 or topK=-1. The equivalent CLI input is mqadmin getLiteGroupInfo -n <namesrv> -p <parent-topic> -g <lite-group> -k 0.
3. The processor reaches getLagCountTopK instead of rejecting the invalid parameter.

The accompanying processor regression test serializes request headers and invokes processRequest. It fails on the unmodified implementation because the invalid request reaches the mocked lag calculator. The constructor behavior above is established from the source path; a live-cluster run and large allocations were not attempted.

What Did You Expect to See?

An INVALID_PARAMETER response with a clear valid range, before calling either lag calculator. Requests for a specific LiteTopic should continue to work without topK, since that path does not use it.

What Did You See Instead?

The aggregate query accepts an unchecked heap capacity and reaches the calculator instead of returning a parameter error.

Additional Context

A small fix can reuse the processor's existing MAX_RETURN_COUNT (10,000), accepting topK in [1, 10000] for aggregate queries. Regression coverage includes null/empty LiteTopic, zero/negative/oversized values, accepted boundaries, and a specific-topic query with the default topK.

I searched existing issues and pull requests for topK and the Lite lag calculator; the related merged PR #10424 optimizes timestamp lookup and does not add this validation.