[FLINK-39711][runtime] Expose maxExceptions on exception message parameters

[jubins]

What is the purpose of the change

Fixes FLINK-39711 - the REST endpoint GET /jobs/:jobid/exceptions accepts an optional maxExceptions
query parameter that bounds the response size, but Java clients of Flink's typed
REST API could not set it: the corresponding MessageQueryParameter fields on
JobExceptionsMessageParameters and ApplicationExceptionsMessageParameters
were declared private. This forced downstream clients (e.g. flink-kubernetes-
operator) to fetch the full job exception history on every observation tick,
wasting network bytes, JobManager-side serialization time, and operator JVM memory
for long-running jobs with large exception histories.

Brief change log

• Changed upperLimitExceptionParameter on JobExceptionsMessageParameters from
  private final to public final, matching the convention used by every other
  MessageParameters subclass (e.g. JobMessageParameters,
  JobMetricsMessageParameters, JobVertexFlameGraphParameters).
• Applied the same change to failureLabelExceptionParameter on the same class,
  which had the identical accessibility gap.
• Applied the same change to upperLimitExceptionParameter on
  ApplicationExceptionsMessageParameters.
• Server-side JobExceptionsHandler / ApplicationExceptionsHandler are
  unchanged — this only opens up the existing parameter to typed Java clients.

Verifying this change

This change is covered by new unit tests:

• JobExceptionsMessageParametersTest — verifies that resolving
  upperLimitExceptionParameter and failureLabelExceptionParameter produces the
  expected query string on the rendered URL, and that optional parameters are
  omitted when unresolved.
• ApplicationExceptionsMessageParametersTest — same coverage for the
  application endpoint.

Existing JobExceptionsHandlerTest continues to validate that the server-side
handler reads the parameter from the request.

Does this pull request potentially affect one of the following parts

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no — neither JobExceptionsMessageParameters nor ApplicationExceptionsMessageParameters carries an @Public/@PublicEvolving annotation. The change only widens field visibility, so it is source- and binary-compatible.
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no — it exposes an existing
  server-side query parameter to Java REST clients.
• If yes, how is the feature documented? n/a

Was generative AI tooling used to co-author this PR?

• Yes — Claude was used as a pair-programming assistant for discussing the approach and implementation structure. All code was written, understood, and verified by the author.

Generated-by: Claude Opus 4.7

[flinkbot]

CI report:

• cada42c Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[spuru9]

@jubins The CI is failing, changes need a lint fix.

[davidradl]

This change looks reasonable. It now enables a server flow, that could not be called before . Is this server side code path tested somewhere? Or do we need to add an integration style test.