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

Bắt đầu bằng cách lần theo việc xử lý TIMEOUT_EXCEEDED trong client-v2 và jdbc-v2, đặc biệt là cách lỗi 159 hiện được thử lại. So sánh việc xử lý các thao tác SELECT, INSERT và DDL hoặc các mutation, sau đó xác định lựa chọn retry theo từng thao tác nên nằm ở đâu. Được xem là hoàn tất khi hành vi retry sau timeout có thể khác nhau tùy thao tác và phản ánh các khác biệt về tính an toàn được mô tả trong bảng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.