Fix SQL value checks for negative expected values

[aaron-y-chen]

Hi team, I found a bug in SQLValueCheckOperator.

If numeric_pass_value_conv=-100 and self.tol=0.1, the resulting range is -90 <= record <= -110, which I don't think matches the expected behavior.

---

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

• No (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[potiuk]

Thanks — this is a real bug, and the report pins it precisely. With pass_value=-100 and tol=0.1 the old expression produced:

-100 * (1 - 0.1) = -90     (lower)
-100 * (1 + 0.1) = -110    (upper)

so the check became -90 <= record <= -110 — unsatisfiable for any input. A negative pass_value with a tolerance could never pass, whatever the data said.

Using abs(v) * tol as a margin is the right fix, and it's a no-op for the positive case (v - v*tol is exactly v*(1-tol)), so there's no regression risk for existing users. Zero behaves identically too.

The part I'd single out as good judgement is extracting _get_tolerance_bounds and calling it from both _get_numeric_matches and the expected_str construction in _build_check_results. The old code duplicated the arithmetic in those two places, which is exactly how a displayed range drifts from the range actually enforced. Now they can't.

Worth knowing: #69736 fixes the same class of bug in the same file — _get_match for SQLColumnCheckOperator/SQLTableCheckOperator around line 744, where check_values["geq_to"] * (1 - tolerance) moves the bound the wrong way for negatives. Different function, same root cause, and it reaches for the same abs(expected) * tolerance shape. They're far enough apart in the file that they shouldn't conflict, but you two may want to compare notes so the two fixes stay consistent.

---

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