The skip-index top-k path (getTopKMarks / MinMaxGranuleItem::operator<)
ranks granules using raw Field comparison, which does not respect
`nulls_direction` or collation semantics. This could cause incorrect
mark skipping for ORDER BY ... NULLS FIRST/LAST or COLLATE queries.

Restrict skip-index top-k to non-nullable numeric types without
collation, where raw Field ordering matches ORDER BY semantics. The
dynamic filtering path (use_top_k_dynamic_filtering) remains fully
available for all types since it uses the corrected comparators in
`TopKThresholdTracker` and `FunctionTopKFilter`.

Add test 04034_top_k_skip_index_nullable_guard covering:
- EXPLAIN verification that skip-index top-k does NOT activate for
  Nullable(UInt32), String with COLLATE, or Nullable(String) with
  COLLATE
- EXPLAIN verification that skip-index top-k still activates for plain
  UInt32
- Dynamic filtering correctness for all the above types with various
  ASC/DESC/NULLS FIRST orderings

Made-with: Cursor

When only `use_skip_indexes_for_top_k` is enabled but the sort column
type is nullable, non-numeric, or uses a collator, `tryOptimizeTopK`
would still call `setTopKColumn` which unnecessarily disables the
query-condition cache.

Add type eligibility checks in `tryOptimizeTopK` (mirroring the guard
in `ReadFromMergeTree::buildIndexes`) so that `setTopKColumn` is only
called when at least one optimization path (skip-index or dynamic
filtering) will actually activate. This avoids performance side effects
from cache disablement on ineligible queries.

Made-with: Cursor

The skip-index top-k path (MinMaxGranuleItem::operator<, getTopKMarks)
uses raw Field comparison that does not respect nulls_direction or
collation. Add a TODO to generalize the comparison so the type
restriction can be lifted.

Made-with: Cursor

Add SELECT 'label' lines before each test query so the reference files
are self-documenting and easier to review.

Made-with: Cursor

…filter

The vectorized path incorrectly used strict `less`/`greater` instead of
`lessOrEquals`/`greaterOrEquals` as on master. The nullable and collation
paths had the same issue with `< 0` instead of `<= 0`. Rows equal to the
threshold must pass the filter to ensure correctness of ORDER BY ... LIMIT.

Also fix `isValueInsideThreshold` to treat equal values as inside the
threshold (matching master's semantics).

Made-with: Cursor

Instead of per-element virtual `compareAt` calls, unwrap the
ColumnNullable, run the vectorized `lessOrEquals`/`greaterOrEquals`
on the nested column, then patch NULL positions with a precomputed
constant derived from direction and nulls_direction.

Made-with: Cursor

- Remove the dead else branch in the collation path (compareAt without
  collation was unreachable since the method is only called when
  collator is set).
- Rename executeWithColumnCompare to executeWithCollation to reflect
  its actual purpose.
- Remove the use_general_comparison field; check collator directly.

Made-with: Cursor

…ldTracker

Replace the three separate fields (direction, nulls_direction, collator)
in `TopKThresholdTracker` with a single `SortColumnDescription`, reducing
redundancy while keeping the public getter API unchanged.

In `FunctionTopKFilter`, replace the complex `executeNullable` path (manual
nullable unwrapping + null patching) and separate `executeWithCollation`
path with a single `executeGeneral` that uses `compareColumn` for
CRTP-devirtualized column-level comparison (non-collation) and per-element
`compareAtWithCollation` for the collation case.

Made-with: Cursor