fix: Preserve casts for horizontal ops with untyped literals

[abhidotsh]

This PR aims to solve for #26723, and is a follow up based on the review from: #26767

As per the https://docs.pola.rs/development/contributing/#pull-requests, here are the screenshots of make test locally passing:

In this PR, AI was used to assist with additional root cause investigation, identifying the fix approach given reviewer feedback on #26767, and initial test generation. However, I confirm the final implementation and test updates were written by me.

@nameexhaustion following up on the last comments regarding args_to_supertype, my understanding of the suggestion was, "can we fix this bug by only changing args_to_supertype?" If that is the case, I could not find a correct fix by only changing args_to_supertype, because the bug is not in the supertype computation. It is that horizontal ops were not opting into the shared coercion pass.

To support the above with some more details:

• Based on my current knowledge/understanding of the polars codebase, args_to_supertype appears to compute a type from a list of dtypes based on this: https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-plan/src/plans/aexpr/function_expr/schema.rs#L809-L832 It does not control whether the function's inputs actually get cast to that type prior to execution. The casting appears to happen in the shared coercion pass right here: https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-plan/src/plans/conversion/type_coercion/mod.rs#L639-L704
• The lower-level supertype computation is already doing the right thing if we look at https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-core/src/utils/supertype.rs#L465-L477 where Polars uses materialize_smallest_dyn_int when combining a concrete numeric type with an unknown integer literal to pick the smallest fitting integer type. For 0, that leads to Int8 via materialize_smallest_dyn_int (https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-core/src/utils/supertype.rs#L652-L663)
• If we contrast the above points with the generic runtime materialization path, it uses materialize_dyn_int which turns small ints into Int32, this can be seen here: https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-core/src/utils/supertype.rs#L611-L618 and which appears to be the mismatch.

To add on to the above points, args_to_supertype is also shared by other functions via map_to_supertype, including FillNull and Coalesce:

• https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-plan/src/plans/aexpr/function_expr/schema.rs#L625-L629
• https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-plan/src/plans/aexpr/function_expr/schema.rs#L66-L66
• https://github.com/abhidotsh/polars/blob/e58a0c3bed13720c2e99725865339dab13eede0b/crates/polars-plan/src/plans/aexpr/function_expr/schema.rs#L47-L47
  This means that if we tried to fix this via args_to_supertype, we would be changing a shared schema helper instead of horizontal-specific behavior.

If the above makes sense, the proper fix should be to not change the supertype computation, but to instead make horizontal ops opt into the shared coercion pass so the literal gets cast to the agreed supertype before the function runs. As part of the fix, the supertyping uses !ALLOW_PRIMITIVE_TO_STRING to prevent min_horizontal(int_col, str_col) from silently coercing to string comparison instead of erroring. This changes the existing error from a runtime ComputeError to a planning-time InvalidOperationError which we can see is reflected in test_raise_invalid_types_21835.

Please let me know if there are any questions/comments/suggestions/concerns, and correct me if my understanding is incorrect on any of the above, given my new (and limited) understanding of the Polars codebase. If there is a specific fix already in mind or any general suggestions on the current PR, please let me know and I am happy to adjust.

[abhidotsh]

This was failing due to the lint error in https://github.com/pola-rs/polars/actions/runs/23468773183/job/68286715771?pr=27011 - currently investigating why this is the case. mypy was locally green for me after doing this:

[abhidotsh]

I see it is failing here for quite a few PRs: https://github.com/pola-rs/polars/actions/workflows/lint-python.yml

If there is a preference to fix this in a separate PR, please let me know.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.47%. Comparing base (4cd2447) to head (960e98e).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #27011      +/-   ##
==========================================
+ Coverage   80.92%   81.47%   +0.54%     
==========================================
  Files        1809     1809              
  Lines      249500   249507       +7     
  Branches     3140     3140              
==========================================
+ Hits       201919   203280    +1361     
+ Misses      46776    45422    -1354     
  Partials      805      805              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.