[client-v2] readVariant discards the active type discriminant — colliding Variant alternatives are indistinguishable

## Description

`BinaryStreamReader.readVariant(ClickHouseColumn)` reads the 1-byte Variant discriminant (`ordNum`) only to select which nested column's reader to run, then returns **just the decoded value** and throws the discriminant away:

```java
// client-v2/src/main/java/com/clickhouse/client/api/data_formats/internal/BinaryStreamReader.java:892
public Object readVariant(ClickHouseColumn column) throws IOException {
int ordNum = readByte() & 0xFF;
if (ordNum == 0xFF) {
return null;
}
return readValue(column.getNestedColumns().get(ordNum)); // ordNum (the active type) is discarded
}
```

For many Variants the active alternative can be inferred from the returned object's runtime class, but for alternatives whose readers produce the **same Java runtime type** the information is lost, and the consumer cannot recover which ClickHouse subtype was actually on the wire. Examples where the decoded objects are indistinguishable:

| Variant | both alternatives decode to | why ambiguous |
| --- | --- | --- |
| `Variant(DateTime, DateTime64(3))` | `java.time.ZonedDateTime` (lines 186-191 → `convertDateTime`, `typeHint == null` → returns `ZonedDateTime`) | same class, same instant |
| `Variant(String, FixedString(N))` | `java.lang.String` | same class |
| `Variant(Decimal32(s), Decimal64(s))` | `java.math.BigDecimal` | same class/scale |

Because `readVariant` returns a bare `Object`, a downstream consumer (text/JSON renderer, type-aware formatter, or any caller inspecting the value) has no way to choose the correct subtype for formatting in these cases.

This is the Java analogue of ClickHouse/clickhouse-js#910. Note the *specific* examples in that JS issue do **not** collide here — `clickhouse-java` maps `Enum8`/`Enum16` to a dedicated `EnumValue` (lines 172-181) and `Date` to `LocalDate` (line 183), so `Variant(UInt8, Enum8(...))` and `Variant(Date, DateTime)` are recoverable from the runtime type. The underlying limitation — the discriminant index is not surfaced — is the same, and other type pairs (above) hit it.

## ClickHouse server version

26.6.1.1193 (collision behavior determined by code analysis of the type→class mapping; not exercised end-to-end against the server).

## Reproduction

A `Variant(DateTime, DateTime64(3))` column: whichever alternative the server picks, `readVariant` returns a `ZonedDateTime`, so the caller cannot tell `DateTime` from `DateTime64`.

```java
// Conceptual unit-level repro against BinaryStreamReader
ClickHouseColumn col = ClickHouseColumn.of("v", "Variant(DateTime, DateTime64(3))");

// Wire bytes: discriminant 0x01 selects the DateTime64 alternative (alternatives are
// sorted by ClickHouse's global type-name ordering), followed by its encoded value.
byte[] payload = /* 0x01 ++ encoded DateTime64 value */;
BinaryStreamReader reader = new BinaryStreamReader(
new ByteArrayInputStream(payload), null, LZ4_FACTORY, null);

Object value = reader.readVariant(col);

// EXPECTED: caller can determine the active alternative was DateTime64 (index 1)
// ACTUAL: value is a java.time.ZonedDateTime, identical to what the DateTime
// alternative (index 0) would have produced — the active type is unrecoverable.
assertTrue(value instanceof ZonedDateTime); // passes for BOTH alternatives
```

The same happens through the high-level reader path (`readValue` → `case Variant` at line 248-250): reading a `Variant(String, FixedString(10))` column yields a `String` with no indication of which alternative it was.

## Suggested fix

Surface the active alternative index alongside the value rather than discarding it — mirroring the upstream proposal. Options:
- Return a small wrapper, e.g. `VariantValue { int typeIndex; Object value; }`, from `readVariant` (breaking change to the public `Object readVariant(...)` signature — gate behind a minor/major bump), or
- Expose the resolved subtype (`column.getNestedColumns().get(ordNum)`) so a renderer can format with the exact `ClickHouseColumn`.

Buggy code: `BinaryStreamReader.readVariant` at `client-v2/src/main/java/com/clickhouse/client/api/data_formats/internal/BinaryStreamReader.java:892-898` (dispatched from `readValue` `case Variant` at line 248-250). The legacy `clickhouse-data` RowBinary processor should be checked for the same pattern.

## Link

Relayed from ClickHouse/clickhouse-js#910.

Start in client-v2/src/main/java/com/clickhouse/client/api/data_formats/internal/BinaryStreamReader.java at readVariant around lines 892-898, then trace the Variant case in readValue around lines 248-250. Compare the proposed wrapper or resolved-subtype approaches and check the legacy clickhouse-data RowBinary processor for the same pattern. Done means callers can distinguish colliding alternatives such as DateTime versus DateTime64, with tests covering the discriminant.

Vom Indexierungsmodell aus dem Issue-Text verfasst.