Fix Core/Downgrade SuperLUDIST resolve skip and StaticArrays.LU init_cacheval regression

[ChrisRackauckas-Claude]

This PR drives the LinearSolve.jl main CI to green by fixing two distinct repo-owned regressions, both introduced by recent HEAD commits.

Fix 1 — Core / Downgrade: skip SuperLUDISTFactorization in the resolve test

The tests / Core (Julia 1, lts, pre) and Downgrade / Core checks share one root cause.

test/Core/resolve.jl iterates over every subtype of AbstractSparseFactorization and calls alg() on each that is not explicitly skipped. PR #1046 ("Add SuperLUDIST sparse factorization support", current HEAD) added SuperLUDISTFactorization as a new subtype, but its constructor calls error(...) unless the LinearSolveSuperLUDISTExt extension is loaded — which requires using MPI, SuperLUDIST, SparseArrays plus an initialized MPI process grid.

The Core resolve test never loads those, so SuperLUDISTFactorization() errored:

LoadError: SuperLUDISTFactorization requires that SuperLUDIST and SparseArrays are loaded, i.e. `using MPI, SuperLUDIST, SparseArrays`

Fix: add SuperLUDISTFactorization to the resolve-loop skip list, exactly like the other extension/hardware-gated factorizations (CudaOffload*, AMDGPUOffload*, MetalLU, BLISLU, CliqueTrees, etc.). SuperLUDIST has its own dedicated test group at test/LinearSolveSuperLUDIST/superludist.jl that exercises the real solve with MPI set up, so it does not belong in the generic single-process resolve loop.

Fix 2 — OrdinaryDiffEq downstream: type StaticArrays.LU has no field factors

The Downstream Tests - InterfaceII (OrdinaryDiffEq) check failed in "Sized Matrix Tests" with:

LoadError: type LU has no field factors
  getproperty @ StaticArrays/.../lu.jl
  init_cacheval(::GenericLUFactorization / ::RFLUFactorization, ...) @ src/factorization.jl

Root cause: PR #1038 ("Handle dense, contiguous non-Array matrices") changed the GenericLUFactorization and RFLUFactorization init_cacheval to rebuild the cached instance via LinearAlgebra.LU(luinst.factors, ipiv, luinst.info) so the cacheval slot type matches the Vector{BlasInt} pivot used by solve! for non-Array dense containers (e.g. FixedSizeArray). That rebuild assumes ArrayInterface.lu_instance(A) returns a LinearAlgebra.LU. For static arrays (SizedMatrix) it returns a StaticArrays.LU, whose fields are L, U, p — no factors/info — so the access threw. A Rodas4 ODE over a SizedMatrix state routes through the default solver → RFLU init_cacheval, hitting this.

Fix: keep the rebuild when lu_instance returns a LinearAlgebra.LU; otherwise build the matching LinearAlgebra.LU directly from the converted matrix and the Vector{BlasInt} pivot — which is exactly what solve! stores for static-array inputs (generic_lufact! / RecursiveFactorization.lu! return LU{T, typeof(A), Vector{BlasInt}}).

Verification

All run locally on Julia 1.12.6 (the CI runner version), StaticArrays 1.9.18, with RecursiveFactorization/Sparspak/CliqueTrees/FixedSizeArrays loaded to mirror the CI extension environment:

• test/Core/resolve.jl: 123/123 pass; the loop now iterates and correctly skips SuperLUDISTFactorization.
• GenericLUFactorization and the default-solver (RFLU) paths both solve a SizedMatrix LinearProblem (residuals ~1e-16 and ~1e-9) — previously errored with the factors FieldError, reproduced before the fix.
• test/Core/fixedsizearrays.jl: 47/47 pass (confirms the LinearAlgebra.LU branch for FixedSizeArray is preserved).

Remaining downstream reds (out of scope — to be fixed in those packages)

• BoundaryValueDiffEq bigfloat_test.jl:68: Expression evaluated to non-Boolean on @test sol4 = solve(prob, MIRKN4(), dt = 0.01) — a BVDE-internal test-writing bug, no LinearSolve involvement.
• ModelingToolkit structural_transformation/utils.jl:182/192: length(mapping) == 5 evaluating to 6 == 5 — an MTK-internal structural-transformation assertion, no LinearSolve involvement.

Please ignore until reviewed by @ChrisRackauckas