fix: BETWEEN optimization now triggers by comparing expr kind, not span

[prql-bot]

Problem

The try_into_between function in SQL codegen was designed to optimize a >= low AND a <= high into a BETWEEN low AND high. However, the optimization never triggered because the equality check a_l == b_l compared full rq::Expr values including their span field. Since the two references to the same column originate from different source positions, they always have different spans, causing the check to fail.

Solution

Changed the comparison from a_l == b_l (full Expr including span) to a_l.kind == b_l.kind (just the expression kind). This is the correct semantic comparison — two column references are equivalent if they refer to the same column, regardless of where they appear in the source.

Testing

• Added test_between_from_comparison verifying from t | filter (a >= 5 && a <= 10) produces a BETWEEN 5 AND 10
• All 517 existing tests pass, including the existing test_ranges test that uses the in operator

---

Closes #5737 — automated triage

[prql-bot]

Duplicate overlap: PR #5738 by @queelius applies the same a_l.kind == b_l.kind fix to try_into_between. One of these should be closed as a duplicate. This PR is more focused (BETWEEN fix only), while #5738 bundles an unrelated SQLite div_i change.

The fix itself is correct — Expr includes span which varies by source position, so comparing .kind is the right semantic check for column equivalence.

[max-sixty]

@prql-bot why did we open a duplicate PR?!

[prql-bot]

Sorry about that — the triage automation opened this PR without first checking whether an existing PR already addressed #5737. PR #5738 by @queelius has the same fix and was opened first.

Closing this as a duplicate in favor of #5738.