[GLUTEN-13201][CORE] Fall back on RANGE frame bounds that cannot be offloaded - #13202

What changes are proposed in this pull request?

Two RANGE window frame shapes failed the query instead of falling back.

On Velox and Bolt, a date order key with an interval bound, e.g. range between interval '1' month preceding and current row, failed planning with UnresolvedException. The range frame boundary pre-computation turns a date key into an integer and adds the bound to it, which only works for an integer bound. It now pre-computes only when every literal bound is integral, and supportWindowExec rejects a literal RANGE bound that is not integral, so the window falls back. The rejection lives in WindowFunctionsBuilder and both backends call it, so the Velox tests cover the code Bolt runs. Both parts are needed: without the first the planning error stays, and without the second the window is offloaded with a constant interval offset that Velox rejects at runtime.

WindowFunctionNode converted literal frame bounds with Long.valueOf. A bound that does not parse as a long, such as the -10.00 a decimal key turns 10 PRECEDING into, threw NumberFormatException, which validation does not turn into a fallback. This matters on ClickHouse, whose supportWindowExec did not check frame bounds. It now throws GlutenNotSupportException, and ClickHouse's supportWindowExec rejects a literal bound that does not parse as a long up front, so the window falls back whether or not native validation is on. Bounds that convert today, such as a decimal(10,0) 10, are still offloaded.

Date keys with integer bounds are still pre-computed and offloaded as before.

How was this patch tested?

VeloxWindowExpressionSuite and BoltWindowExpressionSuite add "range frame with an interval bound on a date key falls back": year-month interval bounds on a date key, and an interval bound next to an integer bound in the same window operator, each compared against vanilla Spark and checked to run as WindowExec. A Spark 4.0+ test does the same for a day interval bound, which Spark 4 also accepts on a date key. WindowFunctionNodeTest checks that decimal, double and null bounds throw GlutenNotSupportException, that an integer bound still converts, that the up-front checks agree with the conversion, and that the Velox/Bolt check rejects a null integral bound. GlutenClickHouseTPCHSaltNullParquetSuite adds "window range with a non-integral bound falls back": 1.5 PRECEDING and 10 PRECEDING on a decimal key are compared against vanilla Spark and checked to run as WindowExec, with native validation both on and off; it runs only on the ClickHouse CI. No CI workflow runs the Bolt suite.

Was this patch authored or co-authored using generative AI tooling?

Yes. Generated-by: Claude Opus.

Related issue: #13201