Preserve scalar arithmetic for small GenericLU systems

[ChrisRackauckas-Claude]

What changed

For matrices of order at most eight, make the blocked GenericLU entry point use the same update arithmetic as the vendored scalar generic_lufact! implementation. This avoids the architecture-sensitive Broyden trajectory regression tracked in SciML/NonlinearSolve.jl#1158 while retaining the blocked kernel for larger matrices.

This also adds a focused comparison against the scalar implementation and bumps LinearSolve from 5.10.0 to 5.10.1.

Please ignore this PR until it has been reviewed by @ChrisRackauckas.

Failure before the fix

Clean NonlinearSolve master fails deterministically on macOS aarch64 with LinearSolve 5.7.0 or later:

4: Wood function | alg #2: Test Failed
  Expression: norm(res, Inf) ≤ ϵ
   Evaluated: 0.00487307057804981 ≤ 0.001

23 Test Problems: Broyden | 93 passed, 1 failed, 21 broken

The same focused LinearSolve test added here fails before the source change on Linux x86_64, Julia 1.12.6:

small path matches scalar arithmetic | 1 pass 1 fail 2 total
blocked generic_lufact! kernel       | 526 pass 1 fail 527 total

The failing assertion is exact factor equality between the small strided path and the vendored scalar implementation.

Boundary

The last green NonlinearSolve macOS run resolved LinearSolve 5.6.0. The first failing run resolved LinearSolve 5.7.0 with the other relevant dependencies unchanged. A formal source bisect identified 6bbb233 as the first trajectory-changing commit.

With current NonlinearSolve sources on Linux x86_64, the Wood problem changes from 1,014 function evaluations on LinearSolve 5.6.0 to 325 on 5.7.0. Both converge on Linux, but macOS aarch64 stops at residual 0.00487307057804981. The test tolerance is unchanged.

Verification after the fix

Focused LinearSolve tests, Julia 1.12.6:

blocked generic_lufact! kernel                       | 527 pass 527 total
GenericLUFactorization through the blocked kernel    | 72 pass 72 total

Focused NonlinearSolve Wood problem with this checkout:

pkgversion(LinearSolve) = v"5.10.1"
sol.retcode = SciMLBase.ReturnCode.Success
sol.stats = SciMLBase.NLStats(1014, 2, 0, 0, 1012)
norm(res, Inf) = 2.5757174171303632e-14

Full local validation:

GROUP=Core JULIA_NUM_THREADS=2 julia +1.12 --startup-file=no --project=. -e 'using Pkg; Pkg.test(; coverage=false)'
GROUP=QA JULIA_NUM_THREADS=2 julia +1.12 --startup-file=no --project=. -e 'using Pkg; Pkg.test(; coverage=false)'

Blocked generic_lufact! kernel | 599 pass 599 total 32.3s
SpecializingFactorizations     | 18 pass 18 total 2.7s
Testing LinearSolve tests passed
Quality Assurance | 49 pass 49 total 12m39.3s
Testing LinearSolve tests passed

The following checks also exited successfully with no output:

julia +1.12 --startup-file=no -e 'using Runic; exit(Runic.main(["--check", "src/blocked_lufact.jl", "test/Core/blocked_lufact.jl"]))'
typos src/blocked_lufact.jl test/Core/blocked_lufact.jl Project.toml
git diff --check

I could not execute macOS aarch64 locally. The macOS failing-before evidence comes from clean-master GitHub Actions; the new arithmetic-equivalence test fails before and passes after on Linux.

Links

• Tracking issue: True-Jacobian Broyden Wood test regressed on macOS with LinearSolve 5.7 NonlinearSolve.jl#1158
• Exact clean-master macOS failure: https://github.com/SciML/NonlinearSolve.jl/actions/runs/31767689486/job/94669721733
• Exact assigned-PR macOS failure: https://github.com/SciML/NonlinearSolve.jl/actions/runs/31797173620/job/94759239832
• Last green macOS control: https://github.com/SciML/NonlinearSolve.jl/actions/runs/31291773452/job/93190218073
• First trajectory-changing commit: 6bbb233

[ChrisRackauckas-Claude]

CI equivalence audit

I compared all three failing downstream jobs with the clean main workflow at the exact base SHA e0719f16f28ca8aa73c3b830976869967053c764. No patch-specific failure was found.

• BoundaryValueDiffEq: both jobs report BigFloat Tests | 3 pass / 2 errors with the same ambiguous promote_rule(BigFloat, SparseConnectivityTracer.Dual) stack. The focused owner fix is Avoid ambiguous reverse promotion in DiffCache PreallocationTools.jl#201.
  • PR: https://github.com/SciML/LinearSolve.jl/actions/runs/31806270231/job/94785830542
  • same-SHA main: https://github.com/SciML/LinearSolve.jl/actions/runs/31790279639/job/94735403436
• ModelingToolkit: both jobs error at discrete_system.jl:289 and :336 on SciMLBase.successful_retcode(sol) with UndefVarError: SciMLBase not defined; both end at 1036 passed, 2 errored, 7 broken.
  • PR: https://github.com/SciML/LinearSolve.jl/actions/runs/31806270231/job/94785830582
  • same-SHA main: https://github.com/SciML/LinearSolve.jl/actions/runs/31790279639/job/94735403506
• SciMLSensitivity Core1: both jobs end at 251 passed, 3 errored, 5 broken with the same Vector{ReverseDiff.TrackedReal} to ReverseDiff.TrackedArray conversion failures.
  • PR: https://github.com/SciML/LinearSolve.jl/actions/runs/31806270231/job/94785830698
  • same-SHA main: https://github.com/SciML/LinearSolve.jl/actions/runs/31790279639/job/94735403394

The ModelingToolkit missing-import failure and SciMLSensitivity tracked-array conversion are the two remaining existing clusters. Neither is caused by this LinearSolve patch.

[ChrisRackauckas]

No change the NonlinearSolve.jl test, just skip it if it's sensitive to this.