Handle dense, contiguous non-Array matrices (e.g. FixedSizeArray) in defaultalg / dense LU caches

[ChrisRackauckas-Claude]

Summary

Fixes #1034. A FixedSizeArray (and any other dense, contiguous, pointer-addressable CPU array that isn't a Base.Array) is <: DenseMatrix and directly LAPACK/BLAS-eligible, but several parts of LinearSolve assumed the dense operator/RHS is specifically a Matrix/Array, so such matrices were either routed to a matrix-free iterative solver or hit a cacheval setfield! TypeError.

Problem 1 — defaultalg routing keyed on the concrete Array type

The selection logic is really about dense, pointer-addressable CPU memory, but it was written against Array:

• The dense direct-factorization branch, the Krylov-cacheval skip, and the dense-vs-sparse QR-fallback-reuse split were gated on A isa Matrix / cache.A isa Array. These are broadened to DenseMatrix, so a dense non-Array matrix routes to a direct factorization instead of falling through to KrylovJL_GMRES (with its accuracy loss).
• The MKLLUFactorization / AppleAccelerateLUFactorization default-selection guards were b isa Array. These are broadened to b isa DenseArray && !(b isa GPUArraysCore.AnyGPUArray) so those BLAS backends are used for dense CPU memory whenever they're faster, regardless of the concrete container. Routing is now container-agnostic: a FixedSizeMatrix resolves to the same algorithm a Matrix of the same size/eltype does (including MKL/Apple where present).

GPU arrays keep their own defaultalg dispatch and are unaffected.

Problem 2 — some dense LU caches assumed Array-typed containers

The cacheval field is type-parameterized, so its type is fixed by init_cacheval and must match what solve! stores:

• GenericLUFactorization / RFLUFactorization: solve! stores a Vector{BlasInt} pivot, but lu_instance(A) types the pivot after A's container (e.g. a FixedSizeVector). The instance is rebuilt with the Vector pivot. (RFLUFactorization is included because the broadened defaultalg can select it for these matrices; it had the same latent bug.)
• MKLLUFactorization / OpenBLASLUFactorization / AppleAccelerateLUFactorization / BLISLUFactorization: the preallocated cache was built from rand(0,0) (a Matrix), so a non-Array dense factorization was the wrong type for the slot. The instance is now built from a 0×0 array of A's own type, and the dense BLAS-eltype method is extended to DenseMatrix{<:BLASELTYPES} (which also now covers Float64 dense containers).

Tests

Adds test/core/fixedsizearrays.jl (over FixedSizeArrays) covering:

• default routing of a dense FixedSizeMatrix to a direct factorization (not GMRES) with direct-LU accuracy;
• container-agnostic routing: defaultalg on a FixedSizeMatrix equals defaultalg on a Matrix of the same size/eltype, across sizes/eltypes (exercises the MKL/Apple guards wherever those binaries exist on CI);
• LUFactorization, GenericLUFactorization, QRFactorization, OpenBLASLUFactorization across Float32/Float64/ComplexF64;
• default solve + re-solve;
• a binary-independent check that the MKL/OpenBLAS/AppleAccelerate cacheval slot tracks A's container (runs even where those binaries are absent).

Local verification

On Julia 1.12 / Linux (OpenBLAS; MKL & AppleAccelerate binaries not present locally):

• The issue's reproducer routes to LUFactorization with resid ≈ 2e-15 (was KrylovJL_GMRES, resid ≈ 1.4e-8).
• GenericLUFactorization and RFLUFactorization no longer throw; OpenBLASLUFactorization works through the real getrf! ccall on a FixedSizeArray — the same ccall pattern MKL/Apple/BLIS use.
• New tests pass (47/47); core/basictests.jl and core/default_algs.jl pass with no regressions.
• MKL/AppleAccelerate routing for FixedSizeArray is verified at the routing level (container-agnostic equality test) and the cache-type level (slot-container test) plus the analogous OpenBLAS end-to-end path; the MKL/Apple ccall itself isn't exercised locally for want of those binaries.

---

Please ignore until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code