…hold and the shard count

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The previous commit renamed `variant_doc_materialization_min_rows` to
`variant_subcolumn_extraction_min_rows` and `variant_doc_hash_shard_count` to
`variant_sparse_shard_count`, and kept the old names as aliases. Both old names belong to doc mode,
whose 4.1 columns already follow the new semantics on the assumption that doc mode is not in use
there, so they are not accepted any more: CREATE TABLE, ALTER TABLE and CAST reject them with the
error for unknown VARIANT properties ("only support for ..."). `variant_sparse_hash_shard_count`,
the shard count that released versions print without doc mode, stays an alias of
`variant_sparse_shard_count`, so their SHOW CREATE TABLE output still parses.

The regression suites that set the doc mode names set the new ones now, and
test_variant_tuning_properties checks that the old ones are refused.

### Release note

`variant_doc_materialization_min_rows` and `variant_doc_hash_shard_count` are no longer accepted; use
`variant_subcolumn_extraction_min_rows` and `variant_sparse_shard_count`. The SHOW CREATE TABLE
output of a doc mode table from 4.1 has to be renamed before it runs.

### Check List (For Author)

- Test: Unit Test, Regression test
    - FE UT: NereidsParserTest, PropertyAnalyzerTest and CreateTableCommandTest, 129 tests,
      0 failures.
    - Regression: the 8 suites whose VARIANT properties changed, where test_variant_tuning_properties
      is regenerated by running it and its two refusals fail with "only support for ..."; and
      check_before_quit, which recreates every table from its SHOW CREATE TABLE and compares.
- Behavior changed: Yes. The two doc mode property names are refused.
- Does this need documentation: Yes, the documentation uses the new names.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

… let MODIFY COLUMN change the row threshold

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812, apache#61100

Problem Summary:

Two choices of the earlier commits went further than renaming the properties:

- `variant_sparse_shard_count` was written into both stored shard fields, `variantSparseHashShardCount`
  and `variantDocShardCount`, and MODIFY COLUMN compared the field of the column's mode instead of
  both fields. The property only has a new name: with doc mode the value belongs to the doc shard
  field and without it to the sparse shard field, as each mode had its own property before. The
  parser now fills that field only and leaves the other one 0, which is what every released version
  stores, so `Column.checkSchemaChangeAllowed` compares the two fields again as master does. The BE
  and SHOW CREATE TABLE already read the field of the mode.
- MODIFY COLUMN refused any change of `variant_subcolumn_extraction_min_rows`, while apache#61100 lets it
  change `variant_doc_materialization_min_rows`. It can change again, with and without doc mode,
  except on a column without doc mode created before this change (a V1 column): its BE ignores the
  threshold, because its count-0 compaction branch cannot extract paths that only the sparse column
  holds, so a value stored there would do nothing. test_variant_modify_doc_materialization_min_rows
  has its steps from master again (an ALTER lowers the threshold and the next compaction extracts the
  old paths), and test_variant_tuning_properties raises the threshold with an ALTER again. The BE
  comment and the UT description of a compaction below the threshold name the ALTER again; the BE
  code does not change.

### Release note

MODIFY COLUMN can change `variant_subcolumn_extraction_min_rows`, but not on a column without doc
mode created before the upgrade.

### Check List (For Author)

- Test: Unit Test, Regression test
    - FE UT: the 11 classes that the VARIANT properties touch (PropertyAnalyzerTest,
      VariantSerializeTypeDdlTest, TypeTest, ColumnTest, SchemaChangeHandlerTest, DataTypeTest,
      NereidsParserTest, VariantLoadParseInjectionTest, CreateTableCommandTest,
      ShowCreateTableCommandTest, SessionVariablesTest), 286 tests, 0 failures.
    - Regression: test_variant_tuning_properties and test_variant_modify_doc_materialization_min_rows,
      regenerated by running them (the latter extracts the same subcolumns as on master); every
      enabled suite of variant_p0 (187), where only outfile_csv_variant_doc_value fails because it
      needs S3 credentials; six suites outside variant_p0 that create VARIANT tables;
      check_before_quit, which recreates every table from its SHOW CREATE TABLE and compares.
- Behavior changed: Yes. MODIFY COLUMN can change the row threshold again.
- Does this need documentation: Yes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

… typed paths to sparse internal

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

- Doc mode columns created before this change (V1, doc mode shipped in 4.1.0 and forced their count
  to 0) keep their layout: they still extract every path once a file reaches the row threshold. The
  load shredder (finish_doc) and the compaction schema (choose_doc_compaction_subpaths) pass the
  column's serialize type instead of V2, so select_variant_paths and get_subpaths give a count of 0
  its V1 meaning, and every doc bucket writer extracts all paths of its bucket. The catalog and
  Nereids VariantType.equals compare the serialize type of a doc column with a count of 0 again. A
  new doc column keeps the new meaning: 0 extracts no dynamic path.
- `variant_enable_typed_paths_to_sparse` is internal now. The property only takes `false`, which
  released versions print in SHOW CREATE TABLE for every column without doc mode, so that DDL still
  runs; `true` is refused ("variant_enable_typed_paths_to_sparse = true is not supported"). A new
  column takes the value from the session variable `default_variant_enable_typed_paths_to_sparse`,
  which only tests set, and a column of an older version keeps its value. SHOW CREATE TABLE and
  DESC do not print it. A restated definition cannot state it, so MODIFY COLUMN no longer compares
  it, and SchemaChangeHandler carries the stored value over as it does the serialize type. The
  regression suites that created columns with `true` set the session variable around those CREATE
  TABLE statements instead.
- Without doc mode only a V2 column has a row threshold: older versions cleared it and MODIFY COLUMN
  refuses one on a V1 column. The load shredder (finish_ordinary) and the compaction schema
  (choose_sparse_compaction_subpaths) therefore compare the rows with it without testing the
  serialize type. The BE unit tests no longer give a V1 column without doc mode a threshold, a state
  that cannot occur.
- Doc mode never moves typed paths to the sparse encoding, so finish_doc asserts that instead of
  testing the flag.
- The doc statistics loop is inlined into aggregate_variant_extended_info, its only caller, and
  choose_compaction_subpaths is renamed choose_sparse_compaction_subpaths, the counterpart of
  choose_doc_compaction_subpaths.

### Release note

Doc mode columns created by 4.1 keep extracting every path. `variant_enable_typed_paths_to_sparse`
cannot be set to `true` any more and is no longer printed by SHOW CREATE TABLE; columns that have it
keep it.

### Check List (For Author)

- Test: Unit Test, Regression test
    - BE UT: `*Variant*:*SchemaUtil*:TabletSchemaTest.*:IndexStorage*`, 1018 run, 1009 passed,
      9 skipped, 0 failed. The 48 cases fewer than before are the V1 columns without doc mode that
      had a threshold. Two VariantShredderTest cases gave the default V1 ordinary layout a threshold
      and now set it for the doc layout only.
    - FE UT: the 11 classes that the VARIANT properties touch, 286 tests, and VariantSerializeTypeDdlTest
      with the new testModifyColumnKeepsTypedPathsToSparse, 4 tests; 0 failures.
    - Regression: the 11 suites whose output printed the property, regenerated by running them; each
      .out only loses the property, and test_all_prdefine_type_to_sparse keeps its subcolumns, so
      the session variable reproduces the layout. test_paimon_catalog_variant.out needs a Paimon
      environment and was edited by hand to the type text test_adbc_type_semantic now prints. Every
      enabled suite of variant_p0 (187), where only outfile_csv_variant_doc_value fails because it
      needs S3 credentials; 20 suites outside variant_p0 that use the property or create VARIANT
      tables; check_before_quit, which recreates every table from its SHOW CREATE TABLE and
      compares. Not run: the two variant_p1 suites and test_index_disk_usage_tvf, which only write
      `false`.
    - clang-format, clang-tidy on the changed lines, checkstyle and check-build-hygiene.sh are clean.
      Inlining the doc statistics loop gives aggregate_variant_extended_info a cognitive complexity
      of 53, so it carries a NOLINT with the reason.
- Behavior changed: Yes. See the release note.
- Does this need documentation: Yes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…f the shard count

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The earlier commits named the shard count of the sparse encoding `variant_sparse_shard_count` and
kept `variant_sparse_hash_shard_count`, the name that released versions use without doc mode, as an
alias. The property keeps its released name instead: `variant_sparse_hash_shard_count` sets the
shard count in both modes (the field of the column's mode, as before), so the DDL of released
versions needs no alias and the alias code goes (renameDeprecatedVariantProperties and its "names of
the same property" error). The doc mode name `variant_doc_hash_shard_count` stays refused. The
session variable is `default_variant_sparse_hash_shard_count` again, as on master, and also sets the
shard count of doc mode. SHOW CREATE TABLE and DESC print `variant_sparse_hash_shard_count`.

Two smaller changes in the doc mode compaction code:

- VariantShredderOptions takes the dynamic paths a compaction chose as a `const PathSet*` instead of
  a std::function that tests the same set; variant_shredder.h includes tablet_schema.h for PathSet.
- Shorter comments on choose_doc_compaction_subpaths, choose_sparse_compaction_subpaths and the
  load branch of finish_doc.

### Release note

The shard count of the sparse encoding keeps its name `variant_sparse_hash_shard_count` and now also
applies with doc mode.

### Check List (For Author)

- Test: Unit Test, Regression test
    - BE UT: `*Variant*:*SchemaUtil*:TabletSchemaTest.*:IndexStorage*`, 1018 run, 1009 passed,
      9 skipped, 0 failed.
    - FE UT: the 11 classes that the VARIANT properties touch, 287 tests, 0 failures.
    - Regression: the 12 suites whose output prints the shard count, regenerated by running them;
      each .out only changes the printed name, except test_variant_tuning_properties, which drops
      the table it created with the old alias. test_paimon_catalog_variant.out needs a Paimon
      environment and was edited by hand to the type text test_adbc_type_semantic now prints. Every
      enabled suite of variant_p0 (187), where only outfile_csv_variant_doc_value fails because it
      needs S3 credentials; 20 suites outside variant_p0 that create VARIANT tables or set the
      session variables; check_before_quit, which recreates every table from its SHOW CREATE TABLE
      and compares.
    - clang-format, clang-tidy on the changed lines, checkstyle and check-build-hygiene.sh are clean.
- Behavior changed: Yes. See the release note.
- Does this need documentation: Yes, the documentation uses `variant_sparse_hash_shard_count`.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…t extract every path

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The serialize type of a VARIANT column (V1 for columns created before the upgrade, V2 for new ones)
is meant to decide one thing: what a subcolumn count of 0 means, every path under V1 and no dynamic
path under V2. MODIFY COLUMN also used it to refuse `variant_subcolumn_extraction_min_rows` on every
V1 column without doc mode, so a table of an older version, whose count is 2048 by default, could
not take a row threshold after the upgrade.

Only a count of 0 needs that refusal. A segment below the threshold leaves its dynamic paths in the
sparse column. A compaction of a V1 column with a count of 0 then chooses every path to extract,
which drops them from the sparse column, but only builds the subcolumns that its inputs extracted, so
the paths that only the sparse column held would be lost. With a count above 0, V1 and V2 behave the
same.

- Column.checkSchemaChangeAllowed refuses a non-zero threshold only on a V1 column without doc mode
  whose count is 0, with a message that says so.
- A load below the threshold uses the V2 meaning of a count of 0 again (extract no dynamic path),
  so a V1 column with a count above 0 does not extract every path there.
- Step 4 of the extended compaction schema ends with an explicit branch for a V2 column with a count
  of 0 and no typed path, which asserts that the compaction chose no path to extract: such a path
  would be dropped from the sparse column with no subcolumn to hold it.

### Release note

MODIFY COLUMN can set `variant_subcolumn_extraction_min_rows` on a VARIANT column without doc mode
that was created before the upgrade, unless its `variant_max_subcolumns_count` is 0.

### Check List (For Author)

- Test: Unit Test, Manual test
    - BE UT: `*Variant*:*SchemaUtil*:TabletSchemaTest.*:IndexStorage*`, 1050 run, 1041 passed,
      9 skipped, 0 failed. The compaction matrix runs V1 columns with a count above 0 with
      thresholds again, expecting the paths of V2.
    - FE UT: ColumnTest (20 tests) and VariantSerializeTypeDdlTest (4 tests), 0 failures; ColumnTest
      covers a V1 column with a count of 2048 taking a threshold and one with a count of 0 refusing it.
    - Manual test on a local cluster: a new column with a count of 0 and no typed path, with and
      without a row threshold, through two loads and a full compaction: no subcolumn extracted, every
      value read back, no assertion. No regression suite was run for this commit.
    - clang-format, clang-tidy on the changed lines, checkstyle and check-build-hygiene.sh are clean.
- Behavior changed: Yes. See the release note.
- Does this need documentation: No.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…to sparse

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The row threshold `variant_subcolumn_extraction_min_rows` now applies with and without doc mode,
but fuzzy mode (`use_fuzzy_session_variable`, on in the p0, p1, nonConcurrent and external
pipelines) still randomized `default_variant_subcolumn_extraction_min_rows` with doc mode only.
`default_variant_enable_typed_paths_to_sparse` is an internal switch for tests now, yet no fuzzy run
ever set it to true: SessionVariable.initFuzzyModeVariables only forced it to false with doc mode.

- initFuzzyModeVariables randomizes the row threshold in both modes, and
  `default_variant_enable_typed_paths_to_sparse` without doc mode. Doc mode keeps it false; the
  parser forces it to false there anyway.
- The parser's "only support for ..." error no longer lists `variant_enable_typed_paths_to_sparse`,
  which is internal now. The property still takes `false` from the DDL of released versions.
- Suites that pin every other fuzzed VARIANT variable now pin these two where their output depends
  on which paths a data file extracts. They were found by running every suite that defines a VARIANT
  column (variant_p0 and 106 others) with the global defaults set to a threshold of 19 and typed
  paths to sparse, then with each one alone, against a run with the defaults:
  - 18 suites pin the threshold to 0: the type text they print shows it, they check MATCH, SEARCH or
    scores with `enable_match_without_inverted_index = false` or need an index on every path, or a
    debug point checks the layout.
  - 3 suites pin typed paths to sparse to false: test_variant_v2_snii_index (count 0, so typed paths
    to sparse leave no indexed path) and both test_array_contains_with_inverted_index (a typed array
    path left sparse keeps an empty array that its subcolumn drops).

### Release note

None

### Check List (For Author)

- Test: Regression test, Unit Test
    - With the global defaults set to a threshold of 19 and typed paths to sparse, before the pins:
      variant_p0 187 suites, 17 failed; 106 other suites, 12 failed. After the pins, the 21 pinned
      suites pass with those settings and with the defaults.
    - Suites that fail with the defaults too, for environment reasons: outfile_csv_variant_doc_value
      (S3 credentials), test_get_tables_schema (arrow flight), test_default_expr and test_json_load
      (time zone), nereids_insert_random, test_bitmap_filter and test_bitmap_filter_nereids
      (databases of other suites), test_ivm_agg_expr_over_agg_1 (enable_feature_changelog).
    - FE UT: NereidsParserTest, 95 tests, 0 failures.
    - checkstyle is clean.
- Behavior changed: No (fuzzy tests and an error message only).
- Does this need documentation: No.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…t extract every path

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The serialize type of a VARIANT column (V1 for columns created before the upgrade, V2 for new ones)
is meant to decide one thing: what a subcolumn count of 0 means, every path under V1 and no dynamic
path under V2. MODIFY COLUMN also used it to refuse `variant_subcolumn_extraction_min_rows` on every
V1 column without doc mode, so a table of an older version, whose count is 2048 by default, could
not take a row threshold after the upgrade.

Only a count of 0 needs that refusal. A segment below the threshold leaves its dynamic paths in the
sparse column. A compaction of a V1 column with a count of 0 then chooses every path to extract,
which drops them from the sparse column, but only builds the subcolumns that its inputs extracted, so
the paths that only the sparse column held would be lost. With a count above 0, V1 and V2 behave the
same.

- Column.checkSchemaChangeAllowed refuses a non-zero threshold only on a V1 column without doc mode
  whose count is 0, with a message that says so.
- select_variant_paths takes the rows of the data file and the shredder options and applies the
  row threshold itself: below it no dynamic path is extracted, whatever the serialize type. The
  load used to pass a count of 0 for that, which under V1 extracts every path, so a V1 column with
  a count above 0 would have extracted every path below the threshold. Both callers, the load
  without doc mode and the load with doc mode, pass the options; the selection is unchanged
  otherwise.
- Step 4 of the extended compaction schema ends with an explicit branch for a V2 column with a count
  of 0 and no typed path, which asserts that the compaction chose no path to extract: such a path
  would be dropped from the sparse column with no subcolumn to hold it.

### Release note

MODIFY COLUMN can set `variant_subcolumn_extraction_min_rows` on a VARIANT column without doc mode
that was created before the upgrade, unless its `variant_max_subcolumns_count` is 0.

### Check List (For Author)

- Test: Unit Test, Manual test
    - BE UT: `*Variant*:*SchemaUtil*:TabletSchemaTest.*:IndexStorage*`, 1050 run, 1041 passed,
      9 skipped, 0 failed. The
      compaction matrix runs V1 columns with a count above 0 with thresholds again, expecting the
      paths of V2. The selection test covers a data file below and at the threshold under V1 and V2.
    - FE UT: ColumnTest (20 tests) and VariantSerializeTypeDdlTest (4 tests), 0 failures; ColumnTest
      covers a V1 column with a count of 2048 taking a threshold and one with a count of 0 refusing it.
    - Manual test on a local cluster: a new column with a count of 0 and no typed path, with and
      without a row threshold, through two loads and a full compaction: no subcolumn extracted, every
      value read back, no assertion. Again after the selection change, with a column of count 2 and
      a threshold of 3 (a 2-row load extracts nothing, a 4-row load its top 2, the compaction of both
      the top 2 of all rows) and a doc mode column of count 1. No regression suite was run for this
      commit.
    - clang-format, clang-tidy on the changed lines, checkstyle and check-build-hygiene.sh are clean.
- Behavior changed: Yes. See the release note.
- Does this need documentation: No.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…to sparse

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The row threshold `variant_subcolumn_extraction_min_rows` now applies with and without doc mode,
but fuzzy mode (`use_fuzzy_session_variable`, on in the p0, p1, nonConcurrent and external
pipelines) still randomized `default_variant_subcolumn_extraction_min_rows` with doc mode only.
`default_variant_enable_typed_paths_to_sparse` is an internal switch for tests now, yet no fuzzy run
ever set it to true: SessionVariable.initFuzzyModeVariables only forced it to false with doc mode.

- initFuzzyModeVariables randomizes the row threshold in both modes, and
  `default_variant_enable_typed_paths_to_sparse` without doc mode. Doc mode keeps it false; the
  parser forces it to false there anyway.
- The parser's "only support for ..." error no longer lists `variant_enable_typed_paths_to_sparse`,
  which is internal now. The property still takes `false` from the DDL of released versions.
- Suites that pin every other fuzzed VARIANT variable now pin these two where their output depends
  on which paths a data file extracts. They were found by running every suite that defines a VARIANT
  column (variant_p0 and 106 others) with the global defaults set to a threshold of 19 and typed
  paths to sparse, then with each one alone, against a run with the defaults:
  - 18 suites pin the threshold to 0: the type text they print shows it, they check MATCH, SEARCH or
    scores with `enable_match_without_inverted_index = false` or need an index on every path, or a
    debug point checks the layout.
  - 3 suites pin typed paths to sparse to false: test_variant_v2_snii_index (count 0, so typed paths
    to sparse leave no indexed path) and both test_array_contains_with_inverted_index (a typed array
    path left sparse keeps an empty array that its subcolumn drops).

### Release note

None

### Check List (For Author)

- Test: Regression test, Unit Test
    - With the global defaults set to a threshold of 19 and typed paths to sparse, before the pins:
      variant_p0 187 suites, 17 failed; 106 other suites, 12 failed. After the pins, the 21 pinned
      suites pass with those settings and with the defaults.
    - Suites that fail with the defaults too, for environment reasons: outfile_csv_variant_doc_value
      (S3 credentials), test_get_tables_schema (arrow flight), test_default_expr and test_json_load
      (time zone), nereids_insert_random, test_bitmap_filter and test_bitmap_filter_nereids
      (databases of other suites), test_ivm_agg_expr_over_agg_1 (enable_feature_changelog).
    - FE UT: NereidsParserTest, 95 tests, 0 failures.
    - checkstyle is clean.
- Behavior changed: No (fuzzy tests and an error message only).
- Does this need documentation: No.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…nt and fail reads of a mismatched layout

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

A review of this PR found two problems and a stale comment.

- CTAS makes every VARIANT column it creates V2, but it kept the count of the query's type. The type of
  a VARIANT expression such as `parse_to_variant` (the default VARIANT type of the planner) has a count
  of 0 under V1, which extracts every path, so `CREATE TABLE t AS SELECT parse_to_variant(s) AS v ...`
  created a column with a count of 0 under V2, which extracts no dynamic path: every path went to the
  sparse column, while 4.1 extracts them all. The same happened when CTAS copies a column of an older
  version with a count of 0, or a VARIANT column of a file table function. Such a type now becomes V2
  with the session's default count (`default_variant_max_subcolumns_count`), as a column declared
  without the count would; a count of 0 that a new column states is kept, and so is the count of a
  nested group column.
- The reader checks that a V2 column with a count of 0 holds no dynamic subcolumn. A BE of an older
  version, which does not know the serialize type, writes such a column with every path extracted, for
  example when an FE is upgraded before every BE. The check was a DORIS_CHECK, so opening such a segment
  crashed the BE, and compaction, which retries the tablet, crashed it again. The check now returns an
  InternalError that names the segment, so the query or the compaction fails instead. It stays an
  error: compaction of such a column folds none of those subcolumns into the sparse column and would
  drop them.
- A comment in LogicalPlanBuilder still said that the property check reads deprecated names; that code
  went away with the rename.

### Release note

None

### Check List (For Author)

- Test: Unit Test, Regression test, Manual test
    - BE UT: `*Variant*:*SchemaUtil*:TabletSchemaTest.*:IndexStorage*`, 1050 run, 1041 passed,
      9 skipped, 0 failed. reader_rejects_dynamic_subcolumn_of_v2_count_zero_column now expects the
      InternalError with the path and the segment file instead of a crash.
    - FE UT: VariantSerializeTypeDdlTest, 6 tests, 0 failures; it covers CTAS of an old column with a
      count of 0, of a VARIANT expression, and of a new column with a count of 0.
    - Regression: test_variant_count_zero_keeps_paths_sparse covers CTAS of `parse_to_variant(...)`; its
      .out was regenerated by the framework and only gains the two new tags. Every suite of variant_p0
      (187), where only outfile_csv_variant_doc_value fails because it needs S3 credentials, and 6 suites
      outside it that run CTAS or views over VARIANT columns.
    - Manual test: the reproduction (CTAS of `parse_to_variant('{"a": 1, "b": 2}')`) gave a count of 0
      and no subcolumn before, a count of 2048 and the subcolumns v.a and v.b after.
    - clang-format, clang-tidy on the changed lines, checkstyle and check-build-hygiene.sh are clean.
- Behavior changed: Yes. CTAS of a VARIANT expression, or of an older column with a count of 0, keeps
  extracting the paths, as in 4.1.
- Does this need documentation: No.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#69812

Problem Summary:

The previous commit gave a column that CTAS creates from a type with a count of 0 under V1 (a column of
an older version, the type of a VARIANT expression such as `parse_to_variant`, or a column of a file
table function) the session's default subcolumn count, so that it kept extracting every path as in
4.1. A column that CTAS creates is a new column, and on a new column a count of 0 means that no dynamic
path is extracted. CTAS keeps the count of the query's type again, as before that commit: such a
column is V2 with a count of 0 and keeps its dynamic paths in the sparse column. Casting the
expression to `VARIANT` in the query gives the column the session's default count instead, because
the target type of the cast is parsed like a declared column.

The reader check and the comment fix of the previous commit stay.

### Release note

CTAS of a VARIANT expression such as `parse_to_variant(...)`, or of a VARIANT column of an older
version with `variant_max_subcolumns_count = 0`, creates a column that extracts no dynamic path,
while 4.1 extracts every path; cast the expression to `VARIANT` to get the default subcolumn count.

### Check List (For Author)

- Test: Unit Test, Regression test, Manual test
    - FE UT: VariantSerializeTypeDdlTest, 6 tests, 0 failures; CTAS of an older column with a count
      of 0, of a VARIANT expression and of a new column with a count of 0 all give V2 with a count of 0.
    - Regression: test_variant_count_zero_keeps_paths_sparse, its .out regenerated by the framework (the
      CTAS of `parse_to_variant(...)` prints a count of 0 and no subcolumn, and reads back the same
      values); test_variant_tuning_properties and the 6 suites outside variant_p0 that run CTAS or
      views over VARIANT columns. 8 suites, 0 failed.
    - Manual test: CTAS of `parse_to_variant('{"a": 1, "b": 2}')` gives a count of 0 and no subcolumn;
      with `CAST(... AS VARIANT)` a count of 2048 and the subcolumns v.a and v.b.
    - checkstyle is clean.
- Behavior changed: Yes. See the release note.
- Does this need documentation: Yes, the CTAS rule goes with the VARIANT documentation.

Co-Authored-By: Claude Opus 5.5 <[email protected]>