…join output

- Blocker: scan.plan() drops value stats, so every split looked unknown and
  the join always collapsed to one task. Read per-file min/max straight from
  the manifest (drop_stats=False), keyed by file name; stats never reach the
  workers.
- Reject FLOAT/DOUBLE range keys (NaN falls out of every range while the hash
  join still matches NaN==NaN -> dropped matches) and TIMESTAMP_LTZ (naive
  manifest stats vs tz-aware column can't be compared).
- Fix the collision check to catch a left key colliding with a right non-key
  column; document that the output keeps the left key names.
- Cap the range count by an unknown-stats read budget so the every-range
  fallback re-reads at most one extra full scan.

The value_stats column names come from value_stats_cols when set, else the
full schema -- the write_cols/schema_id detour resolved wrong names, so every
split looked unknown and the join collapsed to one range. Read min/max via
the same path files_table uses. Update the collision-message assertion.

value_stats.min/max_values are self-describing BinaryRows: they expose
get_field(idx) and their own fields, not a .values list. The previous code
read a non-existent .values attribute, so every split looked unknown and the
join collapsed to one range. Index by the BinaryRow's own field names.

…fest

pypaimon-written tables leave the manifest value stats empty (min/max live
only in the parquet footer), so the manifest approach always saw unknown
ranges and collapsed to one task. Read each split file's footer min/max via
FileIO on the driver; the splits sent to workers still carry no stats.

Verified locally on Python 3.11 (pyarrow+ray): ray_range_join_test 14 passed,
ray_bucket_join_test 18 passed.

Coercing an old file's footer bounds to the current key type is unsafe when
the cast doesn't preserve order: INT->STRING makes 5/100 into '5'/'100', but
'42' > '100' as a string, so a coerced range silently drops the '42' row.

Use a file's footer stats only when it stored the key in the current type;
any other type (schema evolution) marks the split unknown (joins every range).
Also drop the range predicate pushdown -- the reader can't compare a new-type
bound against an evolved file's physical column; the in-memory clip does the
exact, evolution-safe filtering.

Verified locally on Python 3.11: INT->STRING and DATE->TIMESTAMP evolutions
now return the full correct result; ray_range_join_test 16 passed.

…nown ones

The old budget only counted unknown-stats splits, but a known split whose
[lo,hi] spans many ranges is also read once per range (no pushdown; read the
whole split, clip in memory). On poorly clustered input that re-read could
exceed a shuffle. Cap ranges by the actual total re-read -- rows times ranges
each split overlaps -- halving num_ranges until it stays within a couple of
full scans. Document that the feature only benefits clustered inputs.

Verified locally: ray_range_join_test 18 passed (incl. the budget contract for
wide/unknown splits), ray_bucket_join_test 18 passed.

…tes, validate inputs

Review fixes:
- Resolve the range key's footer column by field id, so a renamed/swapped
  (same-type) column reads its own stats instead of another column's.
- Treat a PK table's non-PK range key as unknown: merge (aggregation/partial
  update) can move it past the file min/max, which would silently drop matches.
- Bound re-read by file bytes, not row count, so a wide-row split can't be
  re-read hundreds of times within budget.
- Validate partition keys (reject non-partition columns; None -> is_null) and
  num_ranges (int >= 1, capped at _MAX_RANGES even when passed explicitly).
- Warn instead of silently degrading when a parquet footer read fails.

…e driver

Fail fast for range keys that can't be range-partitioned instead of raising deep
inside a Ray worker: nested/complex types (ARRAY/MAP/ROW/...) and both string
forms of TIMESTAMP WITH LOCAL TIME ZONE (TIMESTAMP_LTZ(p) as well as ... WITH
LOCAL TIME ZONE, only the latter was caught before).

…te all keys

- P0: a range key under auth column-masking is rewritten at read time, so raw
  parquet footer min/max no longer bounds it -> treat as unknown (join every
  range, clip in memory), same fallback as a merge-rewritten non-PK key.
- Validate every join key (not just the range key) up front and reject VARIANT
  as well as nested types, instead of failing as ArrowInvalid inside a worker.
- Fix a stale test comment (footer, not manifest, stats).