fix(drift): read skip index arguments from type_full and ignore stored parens

[any-victor]

Summary

chkit drift reports index_mismatch for a parameterised skip index right after chkit migrate created it. Two causes:

1. Arguments are lost on introspection. system.data_skipping_indices.type holds only the index name (ngrambf_v1). The arguments are in type_full (ngrambf_v1(3, 4096, 2, 0)). parseIndexType therefore parsed every argument as 0, so set(0), bloom_filter(0.01), tokenbf_v1(...), and ngrambf_v1(...) never matched the schema. The TypeScript introspection, the ObsessionDB remote executor, and chkit-py now select type_full AS type.
2. Stored parentheses. chkit renders INDEX name (expr), and ClickHouse keeps those parentheses in expr, so the live expression is (lower(email)) against lower(email) in the schema. The index comparison now drops one pair of parentheses only when it encloses the whole expression, so (a) || (b) stays as written. The TypeScript and chkit-py comparisons both apply it.

Reproduction (ClickHouse 26.9.1.1629)

CREATE TABLE default.t (s String, INDEX a lower(s) TYPE ngrambf_v1(3, 4096, 2, 0) GRANULARITY 1) ENGINE = MergeTree ORDER BY s;
SELECT name, type, type_full, expr FROM system.data_skipping_indices WHERE table = 't';
-- a  ngrambf_v1  ngrambf_v1(3, 4096, 2, 0)  lower(s)

After chkit migrate, expr reads (lower(s)) because of the rendered parentheses.

Relation to #201

#201 canonicalises expressions through formatQuerySingleLineOrNull. That formatter keeps the wrapping pair: SELECT (lower(email)) formats as SELECT (lower(email)) on 26.9. So the parenthesis handling here is still needed alongside #201, and type_full is independent of it. If #201 lands first, the strip applies after canonicalisation.

Test plan

• New e2e case in drift.e2e.test.ts: a table with set(0), bloom_filter(0.01), and ngrambf_v1(3, 4096, 2, 0) indexes reports no drift after migrate. It failed before this change with index_mismatch on all three, and passes after it.
• New unit case in drift.test.ts: stored enclosing parentheses read clean; a changed expression still reports index_mismatch.
• bun run typecheck and bun run lint clean; bun run build green.
• Full test run against a local ClickHouse 26.9.1.1629: all packages green except four chkit e2e tests (three backfill runtime tests and the dictionary lifecycle), which time out at about 33 s here and fail identically on an unmodified main.
• chkit-py: two new cases in test_drift_compare.py (stored enclosing parentheses read clean; (a) || (b) still reports index_mismatch); 1,185 non-e2e tests pass.
• chkit-py end to end against ClickHouse 26.9.1.1629: generate, migrate --apply, then drift --live reports no drift for a table with an ngrambf_v1 index, a toIntervalDay TTL, and a TO materialized view. Before the chkit-py fix it reported index_mismatch on that index.

[Pracxion]

Couldn't we just take the normalizeClause Function?

[KeKs0r]

Good idea, but the regex for that has cases that would lead to issues.
e.g. (a) || (b) -> a) || (b