fix(gfql): temporal comparison and arithmetic conformance (#1915)

[lmeyerov]

Stacked on #1914. Round-010's temporal/UNION findings, B-1 through A-3.

B-1 (severe) — datetime() filters silently matched ZERO rows on tz-naive datetime columns, across ~10 spellings. Two compounding defects:
(a) _gfql_safe_mixed_comparison_op turned a per-element TypeError into False; now pd.NA, per openCypher and per this same file's own stated intent 200 lines above. This is general, not temporal — it is also why RETURN '1.0' < 1.0 answered false. Independent confirmation: two openCypher TCK scenarios flipped from success_wrong_rows to success_matches_expected, and the wrong-row debt bucket is now empty.
(b) A native-datetime detector feeding the temporal comparison path. Deliberately kept separate from order_detect_temporal_mode rather than extending it: that function also drives ORDER BY, and routing real datetime columns through the temporal-key sort would have changed null placement for a working feature.

B-2 — temporal + was string concatenation. Chose real arithmetic over a decline. Temporal literals lower to ISO text before the AST exists, so provenance is gone by evaluator time — but it is intact at fold time, so the arithmetic is constant-folded before engine dispatch and both engines get identical values with no per-engine implementation. Duration month/day/second groups stay separate, so date + PT25H is a no-op, date + P1D advances a day, and date('2020-01-31') + P1M clamps to 02-29. The non-foldable column form now declines typed exactly like its - sibling.

B-3/B-4 — Z-suffix mismatch. polars drops a trailing UTC Z from both operands when a Z-suffixed literal meets a String column (restoring equality and preserving lexicographic order); pandas routes IN [temporal] through the same temporal = with Cypher 3-valued OR. Pinned per engine, not by parity — B-4 was wrong on both engines, so parity testing could never have caught it.

A-1/A-2/A-3 — UNION. Empty branches no longer contribute a type (which alone fixes ['7','8','9'] → [7,8,9]); NaN dedups against None; BOOLEAN keys apart from INTEGER, with concat no longer upcasting True to 1 before dedup runs. Genuinely unrepresentable mixed-type branches decline typed on polars (a polars column cannot hold both '7' and 7) — pinned in both directions.

83 new pins. Zero pygraphistry test changes — nothing asserted the old behavior. Gates: full-tree failure set byte-identical (96 local GPU-less failures both sides), TCK 0 failed with 2 promotions cascaded, typecheck 329, ruff + guards clean.

Honest residuals: B-5 untouched (fixing it would contradict the text-path convention that naive text denotes UTC, which B-1b and B-3 both rely on). B-7's tz-aware-vs-naive column case still raises a raw pandas TypeError — it hits a pushdown path before the row evaluator. And a new cuDF divergence to verify on GPU: the mixed-comparison early-return at row/pipeline.py:608-611 yields all-False for cuDF to avoid a host round-trip, so pandas now returns null where cuDF still returns false — deliberately left rather than blind-editing GPU code that could not be executed locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MF7uRZLKZaD6Q9FGWSmyXi

[lmeyerov]

GPU sweep @211c2885b: 9430 passed, 6 failed — with the parent c6fc1fcda measured in the same session at 9347 passed, 6 failed. Delta +83 passed, 0 new failures, matching the 83 new pins exactly. The 6 failures are byte-identical on both commits and are not from this PR: they are a test-helper bug in the parent's newly-GPU-promoted #1913 pins (AttributeError: 'Series' object has no attribute 'tolist'). Fixed on that branch as be80784b4 — the helper assumed pandas-vs-polars, but a cuDF/polars-gpu request can be served back as a polars Series, and cuDF's Series raises from both to_list and tolist by design, so attribute probing can't discriminate; it now sniffs the module like dtypes.py does and uses to_arrow().to_pylist().

cuDF lane genuinely executed: -k "cudf or gpu" -rs → 1344 passed, single skip is a missing igraph, zero GPU-availability skips.

The flagged cuDF divergence is CONFIRMED and newly introduced by this PR. row/pipeline.py:607-620 early-returns False for any cuDF operand while the pandas path now correctly appends pd.NA. At the parent both engines agreed (both wrong); this fix moved pandas to the openCypher answer and left cuDF behind:

shape	oracle	pandas	cuDF
RETURN '1.0' < 1.0	null	None ✓	False
RETURN NOT ('1.0' < 1.0)	null	None ✓	True
WHERE NOT (n.str_col < 1.0)	[]	[] ✓	['a','b']
WHERE n.str_col < 1.0 (bare)	[]	[] ✓	[] ✓ masked

Only genuinely-incomparable ordering comparisons, and only when the boolean is observed — via NOT or by projecting it. A bare positive WHERE masks it because dropping-on-null and dropping-on-false coincide. The new pin file is pandas/polars only, so nothing catches this; a follow-up will either extend the cuDF path or pin the divergence explicitly.

Good news on the severe finding: B-1 is fixed on both engines — the const-fold and ordering work is engine-agnostic — and at the parent those same cuDF cases raised NotImplementedError: Binary operations with timezone aware operands is not supported, so this PR also repaired cuDF there.