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.

Lies zuerst den Abschnitt “Live compatibility tests” von #238 und das zugehörige Verhalten von #241, und untersuche dann das bestehende Test-Setup, um zu bestimmen, wie der echte HTTP param_*-Pfad ausgeführt werden kann. Entwirf den Speicherort tests/live/ oder einen anderen geeigneten Speicherort und führe die Matrix der deklarierten Typen gegen jede unterstützte ClickHouse-Version aus. Die Aufgabe ist erledigt, wenn akzeptierte oder abgelehnte Ergebnisse pro Version erfasst und Abweichungen zwischen Client und Server identifiziert sind.