Honor iterations in SciPy LinearLUSolver instead of capping at 10

[gaoflow]

Fixes #1208.

Problem

The SciPy LinearLUSolver runs its iterative-refinement loop over range(min(self.iterations, 10)) (linearLUSolver.py:68), silently capping the user-requested iteration count at 10. The PETSc and Trilinos LinearLUSolver implementations both loop over range(self.iterations) with no such cap, so the SciPy backend was inconsistent and ignored iterations set above 10.

As discussed in the issue, LU refinement rarely needs more than a couple of sweeps, but users should still be able to set iterations to whatever they want.

Fix

Drop the cap so the SciPy solver honors iterations like the other backends. The refinement loop still breaks as soon as the residual meets the tolerance, so well-conditioned systems converge in the same one-to-few sweeps as before; only an explicit request for more (or fewer) sweeps is now respected.

Test

Adds a regression doctest to LinearLUSolver, registered for the SciPy solver suite in fipy/solvers/test.py (mirroring the backend-conditional registration in fipy/matrices/test.py). With an unreachable tolerance=0. the loop runs the full requested count, so iterations=12 records 12 refinement sweeps — it recorded 10 before this change.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}