[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. |

首先跟踪 client-v2 和 jdbc-v2 中对 TIMEOUT_EXCEEDED 的处理，尤其是当前如何重试 159 失败。比较 SELECT、INSERT 以及 DDL 或 mutation 的操作处理，然后确定应将按操作选择重试的位置放在哪里。完成的标准是：超时重试行为可以因操作而异，并反映表中描述的安全性区别。

由索引模型根据 Issue 内容生成。