fix: update A_backup before LU to prevent stale QR fallback

[ChrisRackauckas-Claude]

Summary

• Fix stale A_backup causing QR fallback to use wrong matrix when LinearSolve cache is reused across multiple solves
• A_backup was set once from prob.A at init time and never updated
• When NonlinearSolve (or any caller) updates cache.A with new Jacobians via copyto!, the QR fallback would restore from the stale initial matrix instead of the current one

Root Cause

Introduced in v3.59.0 (commit b477d98, "Restore cache.A from prob.A before QR safety fallback"). The A_backup field in DefaultLinearSolverInit stored a reference to prob.A and was never updated when cache.A was modified externally.

When NonlinearSolve's NewtonRaphson solves a system with a singular Jacobian:

1. Each Newton step updates cache.A with the current Jacobian via copyto!
2. LU factorization fails (singular), triggering QR fallback
3. QR fallback does copyto!(cache.A, A_backup) — restoring the initial Jacobian, not the current one
4. QR solves with the wrong matrix, producing wrong Newton steps
5. Newton iteration fails to converge

This caused SciMLBase's downstream initialization.jl tests to fail: NewtonRaphson computed u0[2] = 1.955 instead of 2.0.

Fix

Before each in-place LU factorization, save the current cache.A into A_backup:

if !(cache.A === cache.cacheval.A_backup)
    copyto!(cache.cacheval.A_backup, cache.A)
end

The === guard skips the copy when alias_A=true (same object), preserving existing alias detection logic.

Applied to all 5 LU variant blocks (LU, GenericLU, MKL, AppleAccelerate → shared block; RFLU; BLIS; CUDA; Metal).

Test plan

• Added regression test: cache reuse with different singular matrix, verify QR fallback uses current matrix
• Existing default_algs.jl tests pass
• @test_broken for SparseMatrixCSC{Float64, Int32} now passes (updated to @test)
• Verified NonlinearSolve's NewtonRaphson converges correctly on the SciMLBase initialization scenario
• CI

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Revised approach: sync A_backup in setproperty! instead of the solve path

The previous approach (copyto!(A_backup, cache.A) before each LU variant) had two bugs:

1. Mutated prob.A: A_backup === prob.A (by design), so copyto!(A_backup, cache.A) overwrites the user's problem data through the alias. This caused basictests.jl:108 to fail — values off by exactly 2x because test_interface does cache.A = deepcopy(A2) (where A2 = I/2), triggering the copyto! into prob.A.

2. MethodError on FunctionOperator: Not all A types support copyto! (e.g. FunctionOperator), causing basictests.jl:719 to error.

The fix

Move the sync into Base.setproperty!(cache::LinearCache, :A, x). NonlinearSolve already uses the correct pattern:

copyto!(lincache.A, new_A)
lincache.A = lincache.A  # important!! triggers special code in setproperty!

The new guard x === getfield(cache, :A) && !(x === A_backup) ensures copyto! only fires on this in-place re-trigger pattern (same object re-assigned after mutation), not when a new matrix object is assigned. This is one fix at the interface boundary instead of five copies scattered across every LU variant.

What passes

• All LinearSolve Core tests pass locally (Julia 1.12)
• The NonlinearSolve initialization scenario (NewtonRaphson with singular Jacobian, u0 ≈ [2.0, 1.0]) passes locally
• The @test_broken for SparseMatrixCSC{Float64, Int32} is reverted back since that's still broken (Sparspak Int32 issue, not related)

What this does NOT fix

Issue #887's reproducer (n=20 singular matrix where LUFactorization via LAPACK gives garbage but reports Success) is a pre-existing bug on main — LU doesn't detect the near-singularity, so the QR fallback never triggers. That's a separate issue about singularity detection thresholds, not about stale backups.