[Hakaou]

Closes #589, the second point of the suggested fix in #571. Draft until #575 lands: this branch is stacked on it because it needs the Nested node, so the first commit here is #575's and only the last one belongs to this PR.

Summary

ValidateAST only looked at the root of a type name. Inside Array, Nullable, Tuple, Map, LowCardinality or Nested, a name the parser does not know became a Void terminal, the column was created as ColumnNothing, and the block was read one byte per row, with no error naming the type. CreateColumnByType("Array(Int256)") returned a column typed Array(Void), and SELECT [CAST(1, 'Int256')] returned a row of wrong data without compression and failed with some data was not read with LZ4.

Behavior changes

• The elements of those six containers are validated. A client now gets unsupported column type: Array(Int256) instead of wrong data or an unrelated error, the same error it already gets for Int256 at the root. Other names this applies to, all seen in toTypeName on 26.11: Variant, Dynamic, BFloat16, UInt256, the Interval* types, LineString, MultiPoint, QBit, AggregateFunction.
• The arguments of every other type are left alone: the settings and typed paths of JSON(max_dynamic_paths=1, a Int256, SKIP b) keep decoding as before, and the function name of SimpleAggregateFunction(anyLast, LowCardinality(String)) is not a type.
• Nothing, which the server sends for SELECT [] and SELECT NULL, is registered as the type it already was by accident, so those queries keep working.
• Reject wrapper types built over unsupported nested types #578 covers the neighbouring case of a type the parser accepts but the factory cannot build inside a wrapper. The two change different functions and merge independently.

Tests

• type_parser_ut: a parametrised test with a fresh AST per case, six containers holding an unknown name rejected, Nothing, SimpleAggregateFunction, parameterised JSON, Enum8 and DateTime64 accepted.
• CreateColumnByType_ut: Array(Int256) and Array(Nested(key String, value Dynamic)) give nullptr, Array(Nothing), Nullable(Nothing) and parameterised JSON give a column.
• client_ut, both fixtures: SELECT [] AS empty, NULL AS null_value, [NULL] AS nulls decodes, SELECT [CAST(1, 'Int256')] throws UnimplementedError, and CAST('{"a":1}', 'JSON(max_dynamic_paths=1)') reads back {"a":1} with output_format_native_write_json_as_string = 1.

Full suite green locally (macOS arm64, Apple clang 21) against ClickHouse 26.11.1 master build, except the Remote* tests, which need external TLS endpoints, and Socketcase.connecttimeout, not run. The new tests also pass against 25.12 and 26.3. Parser, factory, types and client suites pass under AddressSanitizer and UBSan, UBSan reporting only the out-of-bounds reads in InsertData that #576 fixes. The branch also builds without warnings with GCC 14 on Linux aarch64, where the server-free suite passes.

Open question

Inside a container, should an unknown name make CreateColumnByType return nullptr, as it does at the root, or would you rather have an exception naming the inner type? With an exception, the parser and factory tests above would expect it instead of false and nullptr, and the client test, which expects UnimplementedError, would hold if that is the type thrown.