[BUG] ISM types lastUpdatedTime is susceptible to int overflow

What is the bug?

Policy and IsmTemplate have fields called lastUpdatedTime, stored as an Integer.
These fields get epoch millis as their values, which are larger than MAX_INTEGER.

https://github.com/opensearch-project/opensearch-java/blob/a903ddfde2c3530c61377dd6a8e17cc2a48358cf/java-client/src/generated/java/org/opensearch/client/opensearch/ism/Policy.java#L159

https://github.com/opensearch-project/opensearch-java/blob/a903ddfde2c3530c61377dd6a8e17cc2a48358cf/java-client/src/generated/java/org/opensearch/client/opensearch/ism/IsmTemplate.java#L103

How can one reproduce the bug?

Use OpenSearchIsmClient and try to GET a policy.

What is the expected behavior?

Successful GET, successful deserialization.

What is your host/environment?

Windows 11, opensearch-java 3.6.0

Do you have any screenshots?

N/A

Do you have any additional context?

If using a JacksonJsonpMapper, then I get an exception like this:

Caused by: com.fasterxml.jackson.core.exc.InputCoercionException: Numeric value (1772134315305) out of range of int (-2147483648 - 2147483647)
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 253]

Using Jackson config like DeserializationFeature.USE_BIG_INTEGER_FOR_INTS does not help, because the target type (eg Policy) explicitly has an an Integer type.

If using a JsonbJsonpMapper, then the value silently overflows and I get a negative timestamp.

Start with the generated fields in java-client/src/generated/java/org/opensearch/client/opensearch/ism/Policy.java and IsmTemplate.java, then reproduce the GET through OpenSearchIsmClient using a JacksonJsonpMapper and a policy containing a large lastUpdatedTime. Verify that both models deserialize epoch-millisecond values successfully without overflow, and add or update coverage wherever the repository tests these generated ISM models.