[BUG][Java][Native] invalid generated code when binary/file responses are mapped to InputStream

Description & Observed Behavior

When generating a Java native client with supportStreaming=true and mapping binary / file types to java.io.InputStream, the generated response handling code contains invalid Java source code.

The generated API method signature correctly uses InputStream as the return type, but the internal implementation still follows the default path—downloading the payload into a temporary file and attempting to return a java.io.File.

This results in the following compilation error:

incompatible types: java.io.File cannot be converted to java.io.InputStream

Affected Configuration:

<supportStreaming>true</supportStreaming>
<typeMappings>
    <typeMapping>file=InputStream</typeMapping>
    <typeMapping>binary=InputStream</typeMapping>
</typeMappings>
<importMappings>
    <importMapping>InputStream=java.io.InputStream</importMapping>
</importMappings>

Expected Behavior

If binary or file is explicitly mapped to InputStream, the generator should:

1. Return the HTTP response body directly as an InputStream without downloading it to a temporary File.
2. Generate valid, compilable Java code.
3. Preserve the default File handling behavior if no custom mapping is specified.

---

Secondary Issue: Raw InputStream request body serialized as JSON

A related problem occurs when sending a raw application/octet-stream request body mapped to InputStream.

Instead of streaming the payload, the generated request builder attempts to serialize the InputStream object via Jackson:

byte[] localVarPostBody = memberVarObjectMapper.writeValueAsBytes(body);
localVarRequestBuilder.method("POST", HttpRequest.BodyPublishers.ofByteArray(localVarPostBody));

This causes the client to send an empty JSON object ({}) instead of the actual binary stream.

Expected Fix for Request Body:
For InputStream / binary inputs, the generator should stream the body directly:

localVarRequestBuilder.method("POST", HttpRequest.BodyPublishers.ofInputStream(() -> body));

Standard application/json payloads should continue to use Jackson serialization.

---

Reproducer & Workaround

Attached is a minimal reproducer project containing:

• OpenAPI 3.0.3 specification
• Minimal Quarkus server (exposing POST /binary/echo and POST /binary/upload)
• Generated Java native client with failing JUnit tests
• A temporary, "quick-and-dirty" api.mustache template override demonstrating the issue area.

Note: Tested against the latest master branch. No existing open or closed issues matching this behavior were found.

openapi_inputstream_bug.zip

Start with the attached quick-and-dirty api.mustache override and the failing JUnit tests in the reproducer, then inspect the generated Java native client for response and request handling. Done means mapped InputStream responses and binary request bodies stream directly, generated code compiles, default File handling remains unchanged, and JSON payloads still use Jackson serialization.