[BUG] string split anchor fuzz test fails with cuDF Glushkov fast path

[thirtiseven]

Describe the bug

RegularExpressionTranspilerSuite deterministically fails in string split fuzz - anchor focused after the CI JNI snapshot changed from build 47 to build 48:

string_split java pattern=\S\r+?\n*
cudfPattern=[^ \u000b\n\t\r\f]\r+?\n*
isRegex=true data=\rbaab\r\ra limit=-1

CPU [2]: \rbaa, \ra
GPU [2]: \rbaa, a

The cuDF Glushkov regex path consumes both consecutive \r characters, while Java and the Thompson path preserve the reluctant +? behavior and consume only one.

The underlying cuDF regression is tracked in rapidsai/cudf#23287.

The failure currently blocks Blossom/pre-merge CI, including #15291.

Steps/Code to reproduce bug

Run the affected suite with the failing JNI/cuDF snapshot:

cd tests
LC_ALL=en_US.UTF-8 mvn -U test \
  -Dbuildver=401 \
  -DwildcardSuites=com.nvidia.spark.rapids.RegularExpressionTranspilerSuite

The data and regex fuzzers both use fixed seeds, so the failure is deterministic with the affected snapshot.

Expected behavior

The GPU split result should match the CPU result:

[\rbaa, \ra]

If the Glushkov engine cannot preserve lazy-quantifier semantics, cuDF should fall back to the Thompson engine.

Environment details (please complete the following information)

• Environment location: NVIDIA Blossom/pre-merge CI
• Spark configuration settings related to the issue: none
• Spark version: 4.0.1
• Scala version: 2.13
• Passing JNI snapshot: 26.08.0-20260714.071523-47-cuda12
• Failing JNI snapshot: 26.08.0-20260716.034120-48-cuda12

Additional context

• Upstream dependency: [BUG] Glushkov regex fast path treats a lazy quantifier as greedy in split_re rapidsai/cudf#23287
• Related cuDF change: Add Glushkov regex fast-path to libcudf rapidsai/cudf#21936
• Failing CI run: https://github.com/NVIDIA/cudf-spark/actions/runs/29471812110
• The same failure appears in unrelated cudf-spark pull requests using the same moving snapshot.
• Temporarily ignore string split fuzz - anchor focused to unblock pre-merge CI. Re-enable the test after the cuDF fix reaches the consumed JNI/cuDF snapshot.

[igorpeshansky]

Verified fixed by rapidsai/cudf#23381, which has been merged into release/26.08.

Suite run (-Dbuildver=400, Scala 2.13, RTX A6000), with #15381 to re-enable the test:

- string split fuzz
- string split fuzz - anchor focused
Tests: succeeded 98, failed 0, canceled 6, ignored 0, pending 0
All tests passed.

Targeted end-to-end check through spark-shell with the built dist jar, comparing GPU against Spark CPU and plain Java regex. The first row is the exact case from the issue description:

MATCH   | pattern=\S\r+?\n* data=\rbaab\r\ra limit=-1
        | GPU  = [\rbaa, \ra]
        | CPU  = [\rbaa, \ra]
        | JAVA = [\rbaa, \ra]
MATCH   | pattern=\S\r+?\n* data=a\r\r\rb   limit=-1
        | GPU  = [, \r\rb]     CPU = [, \r\rb]     JAVA = [, \r\rb]
MATCH   | pattern=a+?b         data=xaaabycaab limit=-1
        | GPU  = [x, yc, ]     CPU = [x, yc, ]     JAVA = [x, yc, ]
MATCH   | pattern=\r+?\n?      data=a\r\rb\r\nc limit=-1
        | GPU  = [a, , b, c]   CPU = [a, , b, c]   JAVA = [a, , b, c]
MATCH   | pattern=\S\r+?\n* data=\rbaab\r\ra limit=2
        | GPU  = [\rbaa, \ra]  CPU = [\rbaa, \ra]  JAVA = [\rbaa, \ra]
SUMMARY: 5/5 cases match (mismatches=0)

The GPU result for the reported case is now [\rbaa, \ra], matching the expected behavior in the issue — the reluctant +? no longer consumes both \r characters.