Fix dense LU cache prototypes for wrapper matrices

[ChrisRackauckas]

Summary

Fixes #1075.

Dense BLAS LU cache initialization was calling ArrayInterface.lu_instance(similar(A, 0, 0)). That works for some dense wrappers, but it can drop wrapper identity before lu_instance gets a chance to dispatch on the actual matrix type.

For ComponentMatrix, the problematic pattern is:

A isa DenseMatrix              # true
similar(A, 0, 0) isa Matrix    # true
lu!(copy(A)).factors isa ComponentMatrix

So the backend cache slot was initialized for an LU with Matrix factors, while solve! later stored an LU with ComponentMatrix factors, causing the setfield! TypeError.

This PR changes the dense BLAS LU cache initializers to ask lu_instance about A directly:

ArrayInterface.lu_instance(A)

That preserves wrapper-specific dispatch for ComponentMatrix and keeps the previous FixedSizeArray behavior.

AppleAccelerate still normalizes the pivot vector to Cint, since that backend stores Cint pivots.

Tests

• Original ODE reproducer from LinearSolve v3.85.2+ broke dense implicit ODE solves with ComponentArray u0 #1075 now succeeds with retcode: Success.
• Focused package test function:
  • test/Core/componentarrays.jl: 10/10
  • test/Core/fixedsizearrays.jl: 47/47
• Wrapper survey checked cache/factor container agreement for:
  • Matrix
  • ComponentMatrix
  • FixedSizeArray

I also ran the Core group far enough to confirm:

• Default Alg Tests: 89/89
• FixedSizeArrays: 47/47
• ComponentArrays: 10/10
• Adjoint Sensitivity: 22/22
• ForwardDiff Overloads: 119/119

The longer Core run later stopped in an existing AppleAccelerate verbosity log-pattern test on this macOS setup. The captured log contained the expected singular-matrix message, but the log matcher failed; this appears unrelated to the LU cache prototype change.