Add GPU support for EnforceSingleRow operator

[perlitz]

Problem

When running Presto TPC-DS queries with cuDF backend enabled, the EnforceSingleRow operator falls back to CPU
execution because no GPU implementation exists. This operator appears 26 times across TPC-DS queries at SF100.

Related to #15772 (tracking issue for missing cuDF operators in TPC-DS)

Description

EnforceSingleRow is a simple operator that validates input produces at most one row and throws an exception if more
than one row is detected. It's commonly used in scalar subqueries.

TPC-DS Queries Affected

Queries using EnforceSingleRow (27 total occurrences across these queries):

• Q6 (1 occurrence) ✓
• Q9 (15 occurrences) - fails due to unrelated NestedLoopJoin issue
• Q14 (3 occurrences) ✓
• Q24 (1 occurrence) ✓
• Q44 (2 occurrences) ✓
• Q54 (2 occurrences) ✓
• Q58 (3 occurrences) ✓

Implementation Approach

The GPU implementation (CudfEnforceSingleRow) should:

1. Accept GPU input and produce GPU output (maintain GPU pipeline continuity)
2. Check row count on GPU using cuDF table APIs
3. Throw VeloxUserError if row count > 1
4. Pass through the single row unchanged
5. Include a config flag cudf.enable_enforce_single_row to allow toggling for performance measurement

Performance Characteristics

Based on benchmarks SF100 data with PR #16357, the GPU implementation shows comparable performance to CPU (±5%
variance), which is expected given:

• The operator is lightweight (just a row count check)
• Typical input is 0-1 rows
• The benefit is avoiding GPU↔CPU transfers in the operator pipeline, not faster execution of the check itself

Implementation Status

• CudfEnforceSingleRow implementation
• Unit tests (EnforceSingleRowTest.cpp)
• Integration with operator adapter registry
• Configuration support (cudf.enable_enforce_single_row)
• PR submitted (will link once created)

Related Work

• Tracking issue: [cuDF] Expand GPU operator support for Presto TPC-DS #15772

[perlitz]

Performance Benchmarks (SF100, 5 iterations)

All queries show no significant performance difference between GPU and CPU implementations, which is expected for
this lightweight operator. The benefit is maintaining GPU pipeline continuity (avoiding GPU↔CPU transfers), not faster
execution of the check itself.

Query	GPU mean±std	CPU mean±std	Diff	t-stat	95% CI	Significant?
Q6 (1 occ)	1.738±0.048s	1.736±0.034s	+0.1%	0.076	[-0.051, +0.055]s	NO
Q14 (3 occ)	11.490±0.309s	11.190±0.165s	+2.7%	1.914	[-0.013, +0.613]s	NO
Q44 (2 occ)	7.294±0.358s	7.102±0.135s	+2.7%	1.121	[-0.151, +0.535]s	NO
Q54 (2 occ)	4.008±0.443s	3.818±0.036s	+5.0%	0.956	[-0.208, +0.588]s	NO
Q58 (3 occ)	3.806±0.123s	3.750±0.053s	+1.5%	0.936	[-0.064, +0.176]s	NO

Methodology: Welch t-test with 95% confidence intervals. "Not significant" means |t| < 2.0 (p ≥ 0.05), indicating
performance differences are within statistical noise.

Test environment: SF100 INT32 data (~43GB), local NVMe storage, NVIDIA RTX PRO 6000 Blackwell, 5 independent runs
per mode.

[karthikeyann]

is the config cudf.enable_enforce_single_row required?

[perlitz]

is the config cudf.enable_enforce_single_row required?

I've added this config to enable the benchmarking of this operator,
Its a design choice, I can easily remove it..