…fields

Each subfield of a named `Tuple` is stored as a separate stream named by the
field path (e.g. `data.c2s.statistics.heros_statistics.damage.bin`), not by
position. Adding a new subfield at any position only introduces new stream
files; all preexisting subfield streams are name-stable and remain valid.
Reading an old part for a newly-added subfield falls back to the type's
default value via the existing `fillMissingColumns` infrastructure, and
the existing CAST(named-Tuple -> named-Tuple-superset) handles whole-tuple
reads element-wise by name.

Extend `isMetadataOnlyConversion` to recognize named-Tuple subfield
additions (recursive, through Array / Nullable / Map / Tuple wrappers).
For named Tuples, every old subfield must still be present by name with a
metadata-only-compatible type, and any new subfields are allowed in any
position. Removing/renaming subfields or changing an existing subfield's
type in a non-metadata-only way still requires a full mutation.

Map recursion is added in the same change to enable
`Map(K, Tuple(a, b))` -> `Map(K, Tuple(a, b, c))` and is naturally
useful on its own.

Impact: on a 2M-row / 1.3 GiB game-analytics table with a deeply nested
`Tuple(Tuple(Array(Tuple(...))))` schema, the customer's
`ALTER MODIFY COLUMN data Tuple(..., new_field Nullable(T))` drops from
~9s (full part rewrite) to ~12ms (metadata only), with no `Mutation`
created and no part rewritten. Subsequent merges materialize the new
subfield's stream files transparently.

…s JSON-hint metadata-only conversions

`tupleAddsSubfieldsOnly` was calling `isMetadataOnlyConversion(..., nullptr)`. When the
caller in `MergeTreeData::checkAlterIsPossible` analyzes an ALTER that combines a Tuple
subfield addition with a JSON-hint-only change (gated by
`allow_experimental_json_lazy_type_hints`), the JSON-hint branch inside
`isMetadataOnlyConversion` requires a context to look up the setting. Without it, the
helper returns false for the JSON change; `tupleAddsSubfieldsOnlyImpl` then concludes
the inner ALTER is not metadata-only and returns false, so the key-safety rejection
is bypassed. Meanwhile `isRequireMutationStage` (called with the real context) sees the
JSON change as metadata-only and skips the mutation branch, so on a key/index column the
ALTER would proceed without rewriting old `primary.idx` or skip-index bytes.

Pass `local_context` from `MergeTreeData::checkAlterIsPossible` through to the helper
so its classification matches `isRequireMutationStage`.

…renced by an explicit skip index

`columns_in_explicit_indices` is populated via `index.expression->getRequiredColumns()`,
which records the literal column reference. For an index over a tuple subcolumn
(e.g. `INDEX idx t.sub TYPE set(0)`), the key is the subcolumn name `t.sub`, not the
storage column `t`. The existing key-safety guard for metadata-only Tuple additions
in `MergeTreeData::checkAlterIsPossible` only looked up the storage column name in
`columns_in_explicit_indices`, so it missed indices keyed on a subcolumn — and the
ALTER would proceed, leaving `skp_idx_*.idx` bytes serialized with the old tuple
shape behind.

Walk the map for any key starting with `column_name + "."` so subcolumn-indexed
`ALTER MODIFY COLUMN t ...` is rejected unconditionally, the same way as the
whole-column-indexed case.

…id false-positive prefix match

The previous metadata-only Tuple-subfield guard checked whether any indexed column
key starts with `column_name + "."`. That aliases a real subcolumn of the altered
storage column (e.g. `t.sub` of column `t`) with an unrelated top-level column
whose name happens to start with that prefix (e.g. column `data.deeper` when
altering `data`).

Resolve each indexed key through `tryGetColumnOrSubcolumn` and only reject when
`getNameInStorage()` matches the column being altered. Add Case 18d to cover the
false-positive that the previous check produced.

…ERT and merge

When all values of a named-Tuple subfield in a part are type-defaults, the
writer omits that subfield's stream files and narrows the part's columns.txt
Tuple type so it no longer mentions the subfield. Reads see the narrowed
Tuple type and use `CAST(narrowed_tuple, full_tuple)` to materialize defaults,
relying on the metadata-only ALTER work in ClickHouse#107305.

This optimization is most useful for `PARTITION BY` schemes where different
partitions populate different subsets of a wide schema's subfields: the
on-disk part keeps only the substreams whose subfield actually appears in
that partition.

Approach

- Reuse the existing whole-column pruning path
  (`IMergedBlockOutputStream::removeEmptyColumnsFromPart` consuming
  `new_data_part->expired_columns`).
- Extend that path to accept dotted subfield names (`data.c2s.gold`) and
  narrow the column's Tuple type via the new
  `narrowDataTypeByExpiredSubstreams` helper in `DataTypes/Utils`.
- After the prune pass, keep `columns_substreams.txt` consistent with the
  on-disk files via the new `ColumnsSubstreams::removeSubstreams` helper.
- Preserve each kept subfield's `SerializationInfo` (its sparse / default
  kind and per-element `num_rows` / `num_defaults`) when narrowing the
  enclosing Tuple, via the new `narrowSerializationInfo` helper.
- INSERT: `MergeTreeDataWriter` traverses each named-Tuple column with the
  new `IColumn::hasOnlyTypeDefaults` to spot all-default subtrees and
  contributes their dotted paths to `expired_columns`.
- Merge (Sub-case A): `MergeTask::prepare` computes the union of leaf
  substreams across all source parts and marks any leaf absent from every
  source as expired in the merged part. This is monotonic: a merged part
  never re-materializes default values for a subfield that was consistently
  pruned in the inputs.

Why top-level all-default columns are intentionally NOT pruned

If we erased a top-level Tuple column whose value is entirely default, the
part would semantically lose that column ("missing column" — equivalent to a
column that was added by a later `ALTER ADD COLUMN`). A subsequent
`ALTER MODIFY COLUMN ... DEFAULT <new_expr>` would then re-materialize the
column with the NEW default expression on read, retroactively changing
historical data. That is exactly the quirk tracked by ClickHouse#92475
(`ALTER MODIFY ... DEFAULT` rewriting old parts).

This PR sidesteps the problem by leaving top-level columns alone: subfield
pruning only narrows the Tuple type of a column that still exists. The
materialized 0 / '' / `[]` bytes of the kept columns pin the part's
semantics; future `ALTER MODIFY ... DEFAULT` changes apply only to parts
written after the ALTER, matching today's whole-column behavior.

Named-Tuple subfields have no per-subfield DEFAULT expression syntax
(`Tuple(a Int64 DEFAULT 5)` is not a valid type), so pruning a subfield can
only ever fall back to the language's type-default (0 / '' / NULL). This is
also why the optimization composes cleanly with the per-column DEFAULT RFC
in ClickHouse#92475 (comment 4334850399): subfield pruning operates entirely below
the column boundary the RFC will redefine.

What is NOT touched

- Compact parts: early return preserved; pruning only fires for Wide parts.
- Patch parts: skipped (mirrors the existing whole-column behavior).
- Mutate path: not pruned; mutations preserve the existing schema.
- Top-level all-default columns: see note above.
- `PR ClickHouse#98472`'s column-level `skip_empty_columns_on_insert` mechanism: only
  the `hasOnlyTypeDefaults` column primitives are lifted, none of its
  signalling layer (no `WITH_SKIPPED_COLUMNS` serialization version, no
  JSON `skipped_columns` field, no DEFAULT-expression interaction).

Gate

- `enable_tuple_subfield_pruning` (default true) gates the entire feature in
  `MergeTreeSettings`. The history entry is recorded under 26.6.

Compatibility

- No on-disk format change: parts written by this PR are readable by any
  server that has the metadata-only-ALTER work in ClickHouse#107305.

Tests

- `tests/queries/0_stateless/04320_tuple_subfield_pruning.sql` exercises 36
  cases: flat / nested Tuple, Nullable wrap, Array(Tuple) (all-empty and
  non-empty), Map(K, Tuple), `LowCardinality(String)`, deep customer-like
  schema, `PARTITION BY` per-partition narrowing, setting OFF, Compact-part
  preservation, two-part merge variants (both pruned, one pruned, different
  subfields pruned), `INSERT SELECT` / async INSERT / materialized view,
  `ReplacingMergeTree` merge, vertical merge, `LWD`, `ALTER MODIFY ADD
  subfield + INSERT`, `ALTER UPDATE` mutation on narrowed part,
  multi-granule part, `DETACH / ATTACH PARTITION`, top-level column with a
  dot in its name, force-sparse + pruning interaction, subcolumn reads of
  pruned subfields, `CHECK TABLE` on a pruned part, and `bytes_on_disk`
  comparison.

### Documentation entry for user-facing changes

- [x] Documentation is not required.

### Changelog category (leave one):

- Improvement

### Changelog entry:

Automatically prune named-Tuple subfields whose values in a part are
entirely type-defaults: the writer omits their stream files and records a
narrowed Tuple type in `columns.txt`; reads materialize defaults via
`CAST`. Gated by the new MergeTree-level setting
`enable_tuple_subfield_pruning` (default on).