bug: "Sent message larger than max" error is retryable

Bug Report

When sending a large payload (e.g. UPSERT with $data parameter exceeding gRPC message limit), the driver returns ResourceExhausted ("trying to send message larger than max"). The problem is that this error is currently treated as retryable. Retrying does not change the situation — the payload size is the same, so every retry fails again with the same error. From the caller's perspective the process effectively hangs (repeated retries until timeout or context cancel), instead of failing fast so the client can reduce batch size or handle the error.

A similar situation was addressed for BulkUpsert and Topic writer. For the Query service (DoTx / Exec with large params), this specific subtype of ResourceExhausted ("message larger than max") should be treated as non-retryable, so that the error is returned to the client immediately. Alternatively, the SDK could handle large messages (e.g. split or document the limit) like for BulkUpsert/Topic.

YDB C++ SDK version:

Any version

Environment

Any environment

Current behavior:

Message retires according to retry configuration

Expected behavior:

• Option A (recommended): Treat ResourceExhausted with description "message larger than max" (and similar parameter size limits) as non-retryable, so the error is returned immediately and the client can reduce batch size or react.
• Option B: Or handle large messages in the SDK (e.g. split before send, or document the limit) like for BulkUpsert/Topic.

Steps to reproduce:

Create an upsert query with huge parameters size

Other information:

Similar issue for go SDK: https://github.com/ydb-platform/ydb-go-sdk/issues/2024

Start by tracing retry handling for the Query service's DoTx and Exec operations, then compare it with the existing BulkUpsert and Topic writer handling. Reproduce an upsert with parameters exceeding the gRPC message limit and verify that the "message larger than max" error is returned immediately without retries.