[Shahzeb-DataEngineer]

Closes #4382

Rationale for this change

StringLiteral.to(IntegerType) and StringLiteral.to(LongType) parsed with Decimal then truncated with plain int(), so "2.6" became 2 and a bound predicate such as x < "2.6" on an int column silently became x < 2, wrongly dropping rows with x = 2 and feeding the same wrong literal into partition pruning. The sibling DecimalLiteral path already rejects fractional values via _to_integral, and the Java reference implementation refuses the conversion entirely. This change reuses _to_integral in both StringLiteral paths.

Are these changes tested?

Yes. New test test_fractional_string_to_integral_type_raises mirrors test_fractional_decimal_to_integral_type_raises; it fails on unpatched code and passes with the fix. test_string_literal updated to no longer assert the truncating behavior. tests/expressions/test_literals.py: 180 passed. tests/expressions/: 594 passed, 2 failed (pre-existing pyparsing-version failures on clean main, verified via git stash). ruff check and ruff format --check clean on both changed files.

Are there any user-facing changes?

Yes, behavior change for the better: converting a fractional string such as "2.6" to an int/long column now raises ValueError at bind time instead of silently truncating. Integral strings ("2.0", "1e3") still convert exactly.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.