fix: Support RANGE window frames over binary ORDER BY keys

[fornwall]

Which issue does this PR close?

• Closes Window functions fail when ORDER BY uses a binary column #24327.

Rationale for this change

A window function over a binary ORDER BY key fails even with no frame clause:

SELECT x, COUNT(*) OVER (ORDER BY x)
FROM (VALUES (arrow_cast('a', 'Binary')), (arrow_cast('b', 'Binary'))) t(x);

Internal error: Cannot run range queries on datatype: Binary.

ORDER BY without a frame defaults to RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and extract_window_frame_target_type had no arm for the binary types. LargeBinary, BinaryView, FixedSizeBinary and dictionary-wrapped binary are affected too. Those bounds only need to compare order key values, which binary supports just as Utf8 does.

A finite offset like 1 PRECEDING is different: the bound is computed as current_value - 1, which needs arithmetic on the order key type. Binary has none, and neither do Utf8, Boolean, List and Null -- yet offset frames over Utf8, Boolean and List keys were accepted, and since 54.0.0 the failing arithmetic is swallowed by the overflow handling from #22140, silently collapsing the bound to the partition edge:

SELECT x, COUNT(*) OVER (ORDER BY x RANGE BETWEEN 1 PRECEDING AND CURRENT ROW)
FROM (VALUES ('a'), ('b'), ('c')) t(x) ORDER BY x;

returns the running count 1, 2, 3 -- a silently widened frame -- instead of an error. This PR rejects such frames at planning time instead, matching PostgreSQL.

What changes are included in this PR?

• Accept the binary types in extract_window_frame_target_type. The existing dictionary arm already recurses into the value type.
• Reject finite RANGE offsets during planning when the target type has no arithmetic, meaning anything other than the numerics and Interval. The message follows PostgreSQL's RANGE with offset PRECEDING/FOLLOWING is not supported for column type ....
• Make WindowFrame::free_range() pub, so the check reuses the crate's existing notion of "bounds that are UNBOUNDED or CURRENT ROW".
• Document the restriction in the window functions guide and the 55.0.0 upgrade guide.

Are these changes tested?

Yes, in window.slt: all four binary types plus dictionary-wrapped binary, ascending and descending, an aggregate and RANK, with duplicate values asserting peer semantics rather than positional counting. Planning errors for offsets over Binary, Utf8, Boolean, List(Int64) and Null, on the end bound as well as the start. Free range frames over Utf8 and Boolean still return results, and Decimal128 keeps its offsets.

The full sqllogictest suite passes.

Are there any user-facing changes?

Yes, one breaking SQL change: RANGE BETWEEN <offset> PRECEDING/FOLLOWING over a Utf8, Binary, Boolean, List or Null ORDER BY key now fails at planning time with RANGE with offset PRECEDING/FOLLOWING is not supported for ORDER BY type .... Over Utf8, Boolean and List keys this replaces the silently widened frames described above; over Null and binary keys such queries already failed at planning time, so only the error message changes. The 55.0.0 upgrade guide entry covers the per-type history and the migration paths: use a ROWS frame to count rows, or state UNBOUNDED PRECEDING / UNBOUNDED FOLLOWING explicitly to compare against the partition edge.

In the other direction, binary order keys now work with free range frames, where they previously raised the internal error above.

WindowFrame::free_range() going from private to pub is additive, so not a breaking Rust API change.

---

AI usage: Created with Claude Code and Opus 5. I have reviewed the code and made modifications where it made sense. I have also tested this end to end in an internal project.