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.

Read #238's “Live compatibility tests” section and the related #241 behavior first, then inspect the existing test setup to determine how the real HTTP param_* path can be exercised. Design the tests/live/ location or another suitable location and run the declared-type matrix against every supported ClickHouse version. Done means accepted or rejected results are recorded per version and client/server divergences are identified.