[client-v2, jdbc-v2] Make execution TIMEOUT error optionally retriable

## Description

Current `159, TIMEOUT_EXCEEDED` is retried unconditionally. It should be a dedicated failure cause selectable per operation because different queries need different behavior:

| Query Type | Scenario | Retriable? | Recommended Action |
| :--- | :--- | :---: | :--- |
| **`SELECT`** | Pure read operations | **Yes** | Retry with exponential backoff or redirect to a replica node. |
| **`SELECT`** | Heavy unoptimized query hitting `max_execution_time` | **No** | Do not retry under identical settings. Increase `max_execution_time` or rewrite query. |
| **`INSERT`** | MergeTree tables with deduplication active (`insert_deduplicate = 1`) | **Yes** | Safe to retry using the exact same data block structure. |
| **`INSERT`** | Tables without block deduplication | **No** | **Unsafe.** Partial blocks may have been written; retrying risks duplicate rows. Check table state first. |
| **`DDL / Mutations`** | `ALTER`, `OPTIMIZE`, or background mutations | **No** | Inspect system tables (`system.mutations`, `system.merges`) before re-executing. |

Start by tracing TIMEOUT_EXCEEDED handling in client-v2 and jdbc-v2, especially how the 159 failure is currently retried. Compare operation handling for SELECT, INSERT, and DDL or mutations, then determine where per-operation retry selection belongs. Done means timeout retry behavior can differ by operation and reflects the safety distinctions described in the table.

Written by the indexing model from the issue text.