client-v2 0.10.0: getTableSchema fails on ClickHouse 26.8 with "Failed to parse column `null` defined by type 'null'" (works on 26.7)

### Describe the bug

`Client.getTableSchema(...)` and `Client.getTableSchemaFromQuery(...)` fail against ClickHouse **26.8** with `Failed to parse column \`null\` defined by type 'null'`. The same code against **26.7** works. It reproduces on a two-column table, so it is not schema-specific.

The server appears to be fine: a raw `DESCRIBE TABLE` issued through the *same client on the same connection* returns every row correctly, and the server's `DESCRIBE ... FORMAT TSKV` bytes are identical between 26.7 and 26.8.

### Steps to reproduce

```java
try (Client client = new Client.Builder()
.addEndpoint(endpoint)
.setUsername("u").setPassword("p").setDefaultDatabase("d")
.compressClientRequest(false).compressServerResponse(true)
.build()) {
client.execute("CREATE TABLE tiny (a UInt8, b String) ENGINE=MergeTree ORDER BY a").get();
client.getTableSchema("tiny"); // OK on 26.7, throws on 26.8
}
```

Result:

```
26.7 tiny OK, columns=2
26.8 tiny FAILED ClientException: Failed to get table schema
root IllegalArgumentException: Non-null columnName and columnType are required
```

### Expected behaviour

`getTableSchema` returns the table's columns, as it does on 26.7.

### Error log

```
com.clickhouse.client.api.ClientException: Failed to get table schema
at com.clickhouse.client.api.Client.getTableSchemaImpl(Client.java:2044)
at com.clickhouse.client.api.Client.getTableSchema(Client.java:2011)
Caused by: com.clickhouse.client.api.ClientException: Failed to parse column `null` defined by type 'null'
at com.clickhouse.client.api.internal.TableSchemaParser.readTSKV(TableSchemaParser.java:33)
at com.clickhouse.client.api.Client.getTableSchemaImpl(Client.java:2036)
Caused by: java.lang.IllegalArgumentException: Non-null columnName and columnType are required
at com.clickhouse.data.ClickHouseColumn.of(ClickHouseColumn.java:676)
```

### Configuration

- **client-v2**: 0.10.0
- **Server**: `clickhouse/clickhouse-server:26.8` (fails) vs `:26.7` (works), official images, default configuration apart from `CLICKHOUSE_DB/USER/PASSWORD`
- **JDK**: 25
- **OS**: Linux container / macOS host

### What I ruled out

Each of these was compared 26.7 against 26.8 directly:

- **The `DESCRIBE` response format.** `DESCRIBE TABLE t FORMAT TSKV` over HTTP is byte-identical on both versions, on a trivial table and on a 56-column one with `Enum8`, `Nullable`, `IPv6`, `LowCardinality` and `DateTime64`. Every line carries a well-formed `name=…\ttype=…`.
- **Response compression.** The LZ4 bodies are identical byte-for-byte, and the failure also occurs with `compressServerResponse(false)`.
- **`describe_include_subcolumns`.** Identical output on both.
- **`default_format` overriding the inline `FORMAT` clause.** Sending `default_format=RowBinaryWithNamesAndTypes` alongside `... FORMAT TSKV` still returns TSKV on both versions.
- **Whether the server or connection is unhealthy.** A raw `DESCRIBE TABLE t` through the same client, on the same connection, immediately before the failing call, returns all rows with correct names and types.

Given `readTSKV` parses each line with `java.util.Properties` and requires `name` and `type` keys, it looks like the response reaching the parser on 26.8 is not the TSKV the server produces for an equivalent request — but I was not able to identify what the client sends differently, and I did not capture the client's own request/response bytes.

I am happy to run further probes against either version if that would help narrow it.

Tái hiện lỗi trên ClickHouse 26.7 và 26.8 bằng Client.getTableSchema và ví dụ có hai cột. Đọc Client.getTableSchemaImpl và internal/TableSchemaParser.java, sau đó kiểm tra request và response của client đi tới readTSKV; hoàn thành khi cả hai phương thức schema đều trả về các cột của bảng trên 26.8 mà không có lỗi null-column.

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