gfql polars-gpu: the fused grouped-aggregate lane and the polars-gpu strictness tests fail on the RAPIDS 26.02 image (plan not GPU-executable on its cudf-polars)

[lmeyerov]

Real-GPU lane on dgx-spark, image graphistry/test-rapids-official:26.02-gfql-polars (cudf 26.02.01, cupy 13.6.0, polars 1.35.2), TEST_CUDF=1, suites test_chain.py / test_hop.py / test_chain_alias_column_collision.py / tests/compute/gfql/**. At master 86de0f5: 13227 passed / 93 failed / 47 xfailed / 4 xpassed. The same 93 fail at the #2056 and #2060 heads (set difference vs master empty), so this is an image/runtime capability gap, not a branch effect:

• tests/compute/gfql/cypher/test_grouped_aggregate_fused_polars.py (matches_eager_twin_and_pandas ×71, serves_total_order_shapes ×8, serves_the_graph_benchmark_shapes ×2, places_nulls_the_opencypher_way ×2): on engine='polars-gpu' the fused lane raises NotImplementedError: GFQL engine='polars-gpu': this query plan is not fully GPU-executable on the installed cudf-polars (NO-CHEATING: we raise rather than silently run it on CPU …) where the tests expect the lane to serve.
• tests/compute/gfql/test_strictness_levels.py polars-gpu cases (absent_return_property_is_null ×2, warns_once, strict_absent_names_raise, quiet_emits_no_warning): same decline.

These pins never run in CI (#1890: polars-gpu executes in no CI lane), so the dgx receipt is the only place they show. Either the fused lane declines to the CPU polars plan on this cudf-polars (typed decline, tests adjusted to expect it on that runtime) or the plan is made GPU-executable; until then every real-GPU receipt carries these 93 as the known baseline.

[lmeyerov]

Root cause, from dumping the failing frame's plan at the lane's collect on dgx: the fused single-hop grouped-aggregate lane's low-cardinality count(*) alternative lowers to col(key).value_counts() + UNNEST, and cudf-polars 26.02 raises NotImplementedError: Unhandled map function unnest. _run_fast_path_on_requested_target turns any NotImplementedError on the GPU target into "declined; plan not GPU-executable, generic route answers", so the generic route answered with the right values and the pins failed on served-by only. Not a dtype problem and not a pre-check false positive on our side (the Invalid type_id text belongs to the strictness cases below).

Fix: #2066 keeps the group_by(...).agg(pl.len()) formulation on the GPU target (cudf-polars executes it; verified on the engine). GPU receipt on the two files: 607 passed / 5 failed at the fix vs 520 / 91 on master.

Remaining on this issue: test_strictness_levels.py polars-gpu cases (MATCH (n) RETURN n.nope_col AS c, 5 pins). They fail on the CPU polars engine too (polars engine does not yet natively support cypher row op 'select'), and once that path runs, the absent-property placeholder in gfql_unified.py:340 is an untyped pl.lit(None) that cudf-polars rejects (Null dtype has no libcudf type_id; pl.lit(None).cast(<dtype>) is fine). So: polars select capability first, then type that literal.