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.

まず #238 の「Live compatibility tests」セクションと、関連する #241 の動作を読んでから、実際の HTTP param_* パスを実行できる方法を判断するために、既存のテスト設定を調査します。tests/live/ または別の適切な場所を設計し、サポート対象のすべての ClickHouse バージョンに対して宣言型のマトリクスを実行します。バージョンごとに受理または拒否された結果が記録され、クライアントとサーバーの相違が特定されれば完了です。