[vvlladd28]

What

Follow-up to #86. thingsboard/thingsboard#16561 also documents limit of getTimeseriesHistory as an int32 integer (4.4.0 took it as String). This adds it to legacyStringParams in openapi/client-compat.json, so once the client is regenerated from the updated specs, PE and PaaS keep deprecated overloads that convert and delegate:

• GetTimeseriesHistoryArgs.Builder limit(String);
• positional getTimeseriesHistory(..., String limit, ...);
• positional getTimeseriesHistoryWithHttpInfo(..., String limit, ..., Map<String, String> headers).

With the current specs limit is still a string, so it is counted as pending: Client compat (pe): AlarmInfo -> Alarm; 29/29 operations, 0/57 params marked, 57 pending (still string).

ClientCompatibilityTest (PE, PaaS) gets 4.4.0-style calls with limit("100") and "100" as the positional argument.

Source-incompatible change that remains after #16561: limit is optional, so a bare null for it (limit(null), getTimeseriesHistory(..., null, ...) in the limit position) becomes ambiguous between the String and Integer overloads. A cast ((Integer) null) or leaving limit out of the builder resolves it. GetTimeseriesHistoryArgs.limit() returns Integer instead of String.

Testing

• ./generate-client.sh all with the current specs: no changes to generated sources.
• mvn clean install (JDK 17) passes; ClientCompatibilityTest 5/5 in PE and PaaS.
• With limit changed to integer/int32 in copies of the PE and PaaS specs: 1/57 params marked, 56 pending; the generated client has the deprecated String limit overloads, compiles, ClientCompatibilityTest passes, and GetTimeseriesHistoryArgs.builder()...limit("100").build().limit() returns Integer 100.