Live ClickHouse compatibility test matrix for declared-parameter types

Problem

#238 (unify the two ClickHouse type parsers, make LowCardinality(T) transparent for parameter validation/serialization) explicitly requires live compatibility tests against real ClickHouse servers:

Run against every supported ClickHouse version using the real HTTP parameter path... Record whether each declaration is accepted by supported server versions. The compatibility test is authoritative for parameter behavior.

This was deferred out of the #238 implementing PR because there's no existing pattern in this repo for hitting a real ClickHouse server from the unit test suite (Playwright e2e is browser-only, against static fixtures/happy-dom).

What's already known (live-verified manually during #238/#241, not automated)

Verified against otel (ClickHouse 26.3.13.20001, Altinity build) via the deployed SPA:

• LowCardinality(String), LowCardinality(UInt32), Array(LowCardinality(UInt64)) — accepted, serialize/execute correctly end-to-end (including a UInt64 value near max, preserved exactly).
• LowCardinality(Enum8(...)) — rejected by the server: Code: 43. DB::Exception: DataTypeLowCardinality is supported only for numbers, strings, Date or DateTime, but got Enum8(...). (ILLEGAL_TYPE_OF_ARGUMENT). This is now correctly reflected client-side (#241): the parser treats LowCardinality wrapping an Enum8/Enum16, in any nesting order, as invalid — no Enum dropdown/membership behavior, degrades to opaque passthrough.

Goal

Build the actual live-compatibility-test scaffolding: a way to run a small matrix of declared-parameter type strings (the ones listed in #238's "Live compatibility tests" section, plus whatever else the LowCardinality-transparency work depends on) against every supported ClickHouse version via the real HTTP param_* path, and record accepted/rejected per version. Use the result to:

• confirm (or correct) which type/wrapper combinations the client should treat as supported vs. permissively-invalid across the whole support matrix, not just one server version;
• catch any other combination (beyond the now-known LowCardinality(Enum...)) where client-side "looks supported" diverges from server-side "actually accepted."

Non-goals

• Building a general live-ClickHouse CI harness for the whole test suite — this is scoped to the parameter-type compatibility matrix only.
• Changing any already-shipped #238/#241 client behavior unless this work finds a real divergence.

Files

Likely a new tests/live/ (or similar, TBD) location — no existing pattern to follow, per #238's PR discussion; this issue owns designing where it lives.

Lisez d’abord la section “Live compatibility tests” de #238 et le comportement associé de #241, puis examinez la configuration de tests existante afin de déterminer comment le véritable chemin HTTP param_* peut être exercé. Concevez l’emplacement tests/live/ ou un autre emplacement approprié et exécutez la matrice des types déclarés avec chaque version de ClickHouse prise en charge. La tâche est terminée lorsque les résultats acceptés ou rejetés sont consignés pour chaque version et que les divergences entre le client et le serveur sont identifiées.