Fix SQLColumnCheckOperator crash on non-numeric column bounds

[shahar1]

SQLColumnCheckOperator checks declared on a date or text column — {"min": {"geq_to": "2020-01-01"}}, {"max": {"leq_to": date(2020, 12, 31)}} — now fail the task with TypeError: unsupported operand type(s) for -: 'str' and 'int'.

#69736 rewrote _get_match so the tolerance margin widens the bound outward for negative expected values, which is correct, but it routed every bound through arithmetic. With no tolerance configured the margin is 0, and bound - 0 still runs — on a bound that cannot be subtracted from. These checks compared cleanly before.

The same rewrite turned equal_to into a degenerate range, so an equal_to check with accept_none=False and a NULL result stopped reporting a failed check and started raising on None <= bound instead.

This keeps the abs()-margin semantics when a tolerance is set and compares the bound directly when it is not.

Verified as a regression: the added tests all pass on 69736's parent commit and all fail on main.

related: #69736

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[potiuk]

Both regressions reproduce exactly as described, and the fix is scoped to the path that broke rather than reverting the earlier work.

The non-numeric bound case is the sharper of the two: returning 0 from the margin helper still meant bound - 0 executed, so a perfectly ordinary check like {"min": {"geq_to": "2020-01-01"}} on a date or text column started failing with a TypeError naming types the user never wrote:

'2020-01-01'                -> unsupported operand type(s) for -: 'str' and 'int'
datetime.date(2020, 12, 31) -> unsupported operand type(s) for -: 'datetime.date' and 'int'

Returning the bound untouched when no tolerance is configured is the right shape — no arithmetic at all, rather than arithmetic that happens to be a no-op for numbers.

The equal_to case matters just as much even though it is quieter. As a degenerate range with margin = 0, a NULL result hit expected <= None <= expected and raised, so accept_none=False stopped reporting a failed check and started crashing the task instead. record == expected gives False, which is the failed check the option is meant to produce.

Good that the abs() widening from #69736 is preserved for the tolerance path — this narrows the fix to the no-tolerance branch instead of undoing the negative-threshold handling.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting