fix(java): stop hardcoding failOnUnknownProperties, and turn it off

[gabooh]

The problem

templates/Java/libraries/jersey3/JSON.mustache replaced the generator's
{{failOnUnknownProperties}} placeholder with a literal true, so the built client rejects any
response property it does not know:

UnrecognizedPropertyException: Unrecognized field "some_field_from_a_newer_server"
(class com.manticoresearch.client.model.SearchResponse), not marked as ignorable

That is not a degraded read. One extra field costs the caller the entire response.

Four things in this repository already say it should be otherwise

• The generator's own default for this option is false, and hardcoding the value means
  --additional-properties failOnUnknownProperties=… cannot reach it at all.
• Every other Java library template here leaves unknown properties alone — apache-httpclient,
  native, restclient, vertx, feign, resteasy, rest-assured, webclient,
  google-api-client, and the shared ApiClient.mustache. Only jersey3 (the library build.sh
  actually builds with), jersey2 and retrofit2 carry the hardcoded literal.
• The schema declares additionalProperties: true on searchResponse, aggBucketsResult and
  aggBucket. The generated Python client honours it (additional_properties), the Go client
  honours it (AdditionalProperties map[string]interface{}) — the Java client contradicts it.
• The README compatibility table promises that a client stays ⚠️ Partially Compatible with a
  newer Manticore Search. With strict deserialization that state cannot exist: the first response
  field a newer server adds turns every search into an exception.

The change

Restore the placeholder on the jersey3 template and pass the option explicitly in do_java(), so
the value is chosen in one visible place rather than frozen in a template. jersey2 and retrofit2
carry the same literal and are left alone here, since nothing builds with them — happy to include
them if you would rather they move together.

What this does and does not do

It makes an unknown property harmless, not readable: a field absent from the schema is dropped.
Fields that callers actually need still have to be modelled — which is a separate concern, and the
subject of #25. Neither change makes the other unnecessary: #25 alone leaves the client brittle
against the next new field, and this one alone would silently drop the metric aggregation values
that #25 makes readable.

How it was verified

Regenerated with OpenAPI Generator 7.17.0 (the version in ./generator-versions), confirmed the
rendered JSON.java now configures the feature to false, and ran the new test against the
regenerated output. Both of its cases throw on the published 10.2.0 client. out/ is deliberately
not included.