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)

Reproduce the failure against ClickHouse 26.7 and 26.8 using Client.getTableSchema and the two-column example. Read Client.getTableSchemaImpl and internal/TableSchemaParser.java, then inspect the client request and response reaching readTSKV; done means both schema methods return the table's columns on 26.8 without the null-column error.

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

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.