Refactor cleanly delegates four ANSI narrow-cast codegen paths (Long→Int and Float/Double→Int/Long) to the existing LongExactNumeric/FloatExactNumeric/DoubleExactNumeric objects in numerics.scala, replacing 5-line inline bodies per call site with a single static call. The getClass.getCanonicalName.stripSuffix("$") pattern matches the well-established convention already used in Cast.scala for IntervalUtils, MathUtils, UTF8StringUtils, etc.

Behavior preserved — the helpers implement the same bounds check (x == x.toInt for Long→Int; Math.floor/ceil for Float/Double→Int/Long) and throw the same castingCauseOverflowError with matching DataType arguments. Deferring byte/short narrowing to SPARK-56910 is sensible since ByteExactNumeric/ShortExactNumeric don't yet expose narrowing methods; the interim if/else inside each helper collapses once that lands. Good call dropping the v1 CastUtils.java in favor of reusing existing infrastructure.

LGTM with one trivial nit inline.

LGTM. The rewrite is behavior-preserving and I verified the equivalence point-by-point against numerics.scala:

• LongExactNumeric.toInt (numerics.scala L112-L118) does if (x == x.toInt) x.toInt else throw castingCauseOverflowError(x, LongType, IntegerType) — same as the original inline body, and the call site at Cast.scala L2138 is gated by case LongType, so the hard-coded LongType/IntegerType in the error match the runtime from/to.
• FloatExactNumeric.toInt|toLong and DoubleExactNumeric.toInt|toLong (numerics.scala L127-L174) implement the same Math.floor(x) <= upper && Math.ceil(x) >= lower check and throw with the same (value, FROM, TO) triple; the call sites at L2140/L2176 are gated by case FloatType | DoubleType.
• The getClass.getCanonicalName.stripSuffix("$") pattern matches ~17 other usages in this file (IntervalUtils, UTF8StringUtils, etc.) and is already exercised in production (e.g. DateTimeUtils calls DoubleExactNumeric.toLong directly). private[sql] object doesn't block Java access — Scala emits the bytecode as public with static forwarders on the companion class.

Two small readability nits, non-blocking:

1. In castFractionToIntegralTypeCode, the from match { case FloatType => ...; case DoubleType => ... } has no default arm. It's safe today because the only callers (L2140, L2176) already gate on FloatType | DoubleType, but it creates an implicit invariant that would silently turn into a MatchError if a new fractional type were ever added and routed here. Consider an explicit case _ => throw SparkException.internalError(...) or a precondition assert.

2. castIntegralTypeToIntegralTypeExactCode is named as a generic integral-narrowing helper, but the int branch now hard-codes LongExactNumeric. That's correct because L2138 (case LongType) is the only path into that branch, but the asymmetry with the byte/short branches (still generic) and with the fraction helper (which does from match) is a bit jarring. Either a one-line doc note ("the int branch is only reachable for from=LongType") or rewriting it as from match { case LongType => LongExactNumeric } for symmetry would read more cleanly.

Neither needs to block this PR.