[GLUTEN-11917][VL] Respect allowPrecisionLoss from expression context in Spark 4.1

[nookcreed]

What changes were proposed in this pull request?

In Spark 4.1, SPARK-53968 introduced NumericEvalContext which captures allowPrecisionLoss at analysis time and embeds it in arithmetic expressions (Add,
Subtract, Multiply, Divide) via an evalContext field.

Previously, Gluten read SQLConf.get.decimalOperationsAllowPrecisionLoss at plan-conversion time. These can diverge — for example, when querying a persistent view whose expression was analyzed under a different session
config. This causes a decimal scale mismatch (e.g. DECIMAL(38,18) + DECIMAL(38,18) producing scale 18 instead of 17 — a 10× error).

Fix: Add a shim method decimalAllowPrecisionLoss(expr: BinaryArithmetic): Boolean:

• Spark41Shims: reads expr.evalContext.allowDecimalPrecisionLoss directly from the expression
• All other Spark versions: fall back to SQLConf.get (preserving existing behavior)

DecimalArithmeticUtil.getResultType and VeloxSparkPlanExecApi.getDecimalArithmeticExprName now use the shim so the correct result type and Velox native function name are selected.

How was this patch tested?

Root cause scenario

The bug triggers when allowPrecisionLoss captured in an expression's NumericEvalContext at analysis time differs from the current SQLConf at plan-conversion time. The canonical case is querying a persistent view whose
decimal arithmetic was analyzed under one config:

-- View analyzed with allowPrecisionLoss=true (default)
-- DECIMAL(38,18) + DECIMAL(38,18) → Spark computes result type as DECIMAL(38,17)
CREATE VIEW v AS SELECT col1 + col2 AS result FROM t;

-- Query run in a session with allowPrecisionLoss=false
SET spark.sql.decimalOperations.allowPrecisionLoss=false;
-- Old code: reads SQLConf → uses false → computes DECIMAL(38,18), calls add_deny_precision_loss
-- New code: reads expr.evalContext → uses true → computes DECIMAL(38,17), calls add
SELECT * FROM v;
-- Scale mismatch: 18 vs 17 = 10× error

Existing test (no regression)

MathFunctionsValidateSuite#decimal arithmetic (backends-velox) already covers allowPrecisionLoss=true/false toggled within a single session via withSQLConf. This test continues to pass because expression creation and plan
conversion both happen inside the same config scope.

./dev/run-scala-test.sh
-Pjava-17,spark-4.1,scala-2.13,backends-velox,hadoop-3.3,spark-ut
-pl backends-velox
-s org.apache.gluten.functions.MathFunctionsValidateSuite
-t "decimal arithmetic"

Fixed test: GlutenSQLQuerySuite

The exclusion on line 1047 of VeloxTestSettings.scala (spark41) should be removed and the test should now pass:

./dev/run-scala-test.sh
-Pjava-17,spark-4.1,scala-2.13,backends-velox,hadoop-3.3,spark-ut
-pl gluten-ut/spark41
-s org.apache.spark.sql.GlutenSQLQuerySuite
-t "should be able to resolve a persistent view"

GlutenSimpleSQLViewSuite (partial — 1 of 2 failures)

GlutenSimpleSQLViewSuite is currently fully disabled (// TODO: 4.x enableSuite on line 701). This PR resolves 1 of its 2 failures; the remaining failure is tracked in #11912. The suite can be re-enabled with an exclusion for
the #11912 test once that test name is identified from a CI run.

CI

Trigger Velox CI on the PR to run the full spark-ut suite against Spark 4.1.

---

Closes #11917

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86

[github-actions]

Run Gluten Clickhouse CI on x86