Numeric-to-string cast interval inference can reject valid filters with reversed bounds

[haohuaijin]

Describe the bug

A view that exposes integer IDs as strings can fail when a downstream query casts the IDs back to integers for filtering. With Parquet values 2 and 10, the valid predicate CAST(id AS INT) > 1 fails with an internal error:

Interval's lower bound 2 is greater than the upper bound 10.

All values are valid and fit in INT. No ORDER BY or numeric overflow is needed.

To Reproduce

Reproduced on main at d20936c using the SQL logic test runner. Use a fresh output path for the Parquet file.

COPY (
    SELECT column1 AS id FROM (VALUES (2), (10))
) TO '/tmp/ids_repro.parquet' STORED AS PARQUET;

CREATE EXTERNAL TABLE ids STORED AS PARQUET
LOCATION '/tmp/ids_repro.parquet';

CREATE VIEW text_ids AS
SELECT CAST(id AS VARCHAR) AS id FROM ids;

SELECT id
FROM text_ids
WHERE CAST(id AS INT) > 1;

The final query fails with the interval-bound assertion above.

Expected behavior

The final query should return the strings '2' and '10' (in either order), without an error.

Additional context

The Parquet statistics provide the numeric interval [2, 10]. After view expansion, forward interval evaluation attempts to cast its endpoints to strings, producing ["2", "10"]. Under string ordering, "2" > "10", so Interval::try_new rejects the interval before the outer string-to-integer conversion.

check_support currently recurses through a CastExpr without checking whether the conversion supports endpoint-based interval inference. Numeric order and string order are not interchangeable.

Related to #25528 and #25531, but distinct: #25528 addresses inferred numeric endpoint overflow, and #25531 restricts reverse cast constraint propagation. This reproduction concerns forward interval evaluation and already fails on main independently of those PRs.