[Bug] InternalServerErrorException swallows error details from getMessage(), hiding OpenSearch server errors from JDBC clients

Start with InternalServerErrorException.java in org.opensearch.jdbc.protocol.exceptions and inspect how its constructor initializes the server error fields and parent SQLNonTransientException. Check similarly structured exception classes for the same behavior. Done means JDBC clients receive the OpenSearch reason, type, and details through getMessage() instead of null.

Describe the bug

When the OpenSearch server returns an HTTP 500 error (such as Internal Server Error / all shards failed) via the SQL API, the opensearch-sql-jdbc driver fails to expose the error reason and details through standard JDBC Exception handling.

Specifically, the InternalServerErrorException class (and potentially other exception classes in org.opensearch.jdbc.protocol.exceptions) does not pass a formatted error message to its parent SQLNonTransientException via super(message), nor does it override getMessage().

As a result, standard JDBC clients (like logstash-input-jdbc) that rely on Exception.getMessage() will simply output null. For example, Logstash logs:

Java::OrgOpensearchJdbcProtocolExceptions::InternalServerErrorException: null

This completely swallows the actual OpenSearch server error, making it incredibly difficult for users to debug SQL failures through the JDBC driver.

To Reproduce

Steps to reproduce the behavior:

1. Connect a JDBC client (e.g., Logstash logstash-input-jdbc or DBeaver) to OpenSearch using the opensearch-sql-jdbc driver.
2. Execute a query that intentionally triggers a server-side runtime error (for example, triggering all shards failed by passing an invalid CAST or date format during a cursor-based fetch).
3. Check the client logs. The actual JSON error response from OpenSearch containing the reason and details is swallowed, and the client only receives a null message.

Expected behavior

The exception should expose the reason and details when getMessage() is called, so that JDBC clients can log the true root cause.

Proposed Fix

Update InternalServerErrorException.java (and similarly structured exceptions) to either override getMessage() or pass a formatted message to the super constructor:

    public InternalServerErrorException(String reason, String type, String details) {
        // Pass the error message to the parent Exception class
        super(String.format("Reason: %s, Type: %s, Details: %s", reason, type, details));
        this.reason = reason;
        this.type = type;
        this.details = details;
    }