Merge 'fix: adjust jump_if_null branch offset as incorrectly failed NULL in check constraints in integrity checks' from Pedro Muniz

Caught by differential fuzzer
`PRAGMA integrity_check` incorrectly flagged rows with NULL values as
CHECK constraint violations. Per the SQL standard, NULL does not violate
CHECK constraints — SQLite correctly allows NULLs and reports `ok` on
integrity check, but Turso's integrity check reported false positives
like:
```
CHECK constraint failed in t1
```
This was the root cause of 3 fuzzer-reported "data corruption" failures
(seeds: `4713306089706541904`, `13879125450750994315`,
`16798752381237836570`). The data itself was correct — only the
integrity check diagnosis was wrong.
### Reproducer
```sql
CREATE TABLE t1 (id INTEGER PRIMARY KEY, val REAL CHECK (val > 0));
INSERT INTO t1 (id, val) VALUES (1, NULL);  -- NULL passes CHECK (correct)
PRAGMA integrity_check;
-- SQLite: ok
-- Turso (before fix): CHECK constraint failed in t1
-- Turso (after fix):  ok
```
### Root Cause
In `core/translate/expr.rs`, `emit_binary_condition_insn` controls the
`jump_if_null` flag on comparison instructions (`Gt`, `Lt`, `Eq`, etc.).
The flag was only set when `jump_if_condition_is_true == false` (the
common WHERE clause path). When `jump_if_condition_is_true == true` (as
used by integrity_check), NULL comparisons fell through to the error
path instead of jumping to the "check ok" label.
The integrity check emits CHECK validation with
`jump_if_condition_is_true: true` and `jump_target_when_null: check_ok`,
but the comparison instruction had no `jump_if_null` flag, so `NULL > 0`
evaluated to NULL, didn't jump, and fell through to report a false
violation.
### Fix
Changed the `jump_if_null` flag logic to be driven by whether
`jump_target_when_null` matches the jump target, rather than being
hardcoded per direction:
- `jump_if_condition_is_true == true`: set `jump_if_null` when
`null_target == true_target`
- `jump_if_condition_is_true == false`: set `jump_if_null` when
`null_target == false_target`
This is backward-compatible — all existing callers with
`jump_if_condition_is_true == false` already have `null_target ==
false_target`.
Claude did it all

Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>

Closes #5495

Author: jussisaurio

core/translate/expr.rs

@@ -3823,13 +3823,17 @@ fn emit_binary_condition_insn(
         opposite_op
     };
 
-    // Similarly, we "jump if NULL" only when we intend to jump if the condition is false.
-    let flags = if condition_metadata.jump_if_condition_is_true {
-        CmpInsFlags::default().with_affinity(affinity)
-    } else {
-        CmpInsFlags::default()
-            .with_affinity(affinity)
-            .jump_if_null()
+    // Set the "jump if NULL" flag when the NULL target matches the jump target.
+    // When jump_if_condition_is_true: we jump on true, so set jump_if_null when NULL should also jump (e.g. CHECK constraints in integrity_check).
+    // When !jump_if_condition_is_true: we jump on false, so set jump_if_null when NULL should also jump (standard SQL 3-valued logic).
+    let mut flags = CmpInsFlags::default().with_affinity(affinity);
+    if condition_metadata.jump_if_condition_is_true {
+        if condition_metadata.jump_target_when_null == condition_metadata.jump_target_when_true {
+            flags = flags.jump_if_null()
+        }
+    } else if condition_metadata.jump_target_when_null == condition_metadata.jump_target_when_false
+    {
+        flags = flags.jump_if_null()
     };
 
     let target_pc = if condition_metadata.jump_if_condition_is_true {

testing/runner/tests/check_constraint.sqltest

@@ -1655,14 +1655,33 @@ expect {
 # Bug fix: CHECK constraint type coercion must use column affinity (#5170)
 # TEXT column comparing with integer literal should use TEXT affinity,
 # meaning the integer is coerced to text for comparison.
-test check_constraint_text_affinity_coercion_violation {
-    CREATE TABLE t(val TEXT CHECK(val > 5));
-    INSERT INTO t VALUES ('10');
+# Bug fix: integrity_check must not flag NULL values as CHECK violations.
+# Per SQL standard, NULL does not violate CHECK constraints.
+@skip-if mvcc "MVCC integrity_check does not perform row-level CHECK validation"
+test check_constraint_integrity_check_null_not_violation {
+    CREATE TABLE t(id INTEGER PRIMARY KEY, val REAL CHECK (val > 0));
+    INSERT INTO t (id, val) VALUES (1, 100.0);
+    INSERT INTO t (id, val) VALUES (2, NULL);
+    INSERT INTO t (id, val) VALUES (3, 200.0);
+    PRAGMA integrity_check;
 }
-expect error {
-    CHECK constraint failed: val > 5
+expect {
+    ok
 }
 
+@skip-if mvcc "MVCC integrity_check does not perform row-level CHECK validation"
+test check_constraint_integrity_check_detects_real_violation {
+    CREATE TABLE t(id INTEGER PRIMARY KEY, val INTEGER CHECK (val > 0));
+    PRAGMA ignore_check_constraints = ON;
+    INSERT INTO t VALUES (1, -5);
+    PRAGMA ignore_check_constraints = OFF;
+    PRAGMA integrity_check;
+}
+expect {
+    CHECK constraint failed in t
+}
+
+
 test check_constraint_text_affinity_coercion_pass {
     CREATE TABLE t(val TEXT CHECK(val > 5));
     -- '6' > '5' in text comparison is true