IterativeSolvers: fix MINRES residual field and IDRS keyword forwarding

[AJ0070]

Fixes #24.

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Found while checking whether #181 still reproduces. It does not, but two IterativeSolvers algorithms turned out to be broken outright, which is what #24 reports.

MINRES threw on every solve

solve! read cache.cacheval.residual unconditionally. MINRESIterable calls that field resnorm, so IterativeSolversJL_MINRES failed with FieldError: type IterativeSolvers.MINRESIterable has no field 'residual' for any input. Residual extraction is now per iterable type, which also keeps the existing IDRSIterable special case in one place.

IDRS threw whenever tolerances were passed as algorithm kwargs

idrs_iterable! takes abstol, reltol and maxiter positionally and accepts only smoothing and verbose as keywords. The filter dropped idrs_s alone, so IterativeSolversJL_IDRS(abstol = 1e-10) forwarded abstol a second time as a keyword and failed with a MethodError. All four positionally passed names are now dropped. IterativeSolversJL_IDRS() with no kwargs was unaffected, which is why the existing tests missed it.

Test coverage

• MINRES is enabled in the IterativeSolversJL testset, where it had been commented out. It passes the full test_interface on both the real and complex problems plus test_tolerance_update.
• BICGSTAB stays commented out, now with the reason recorded. It fails differently: IterativeSolvers' own bicgstabl breaks down on the identity prob1 and throws ArgumentError: matrix contains Infs or NaNs out of LAPACK. That is upstream numerics rather than anything wired wrong here, so it is not in scope.
• A new case covers tolerances passed as algorithm kwargs for IDRS, MINRES and CG. The existing testset only ever passed gmres_restart, so it could not have caught the IDRS bug.

Notes for review

• That new test asserts the solution rather than successful_retcode. This extension calls build_linear_solution without a retcode, so every IterativeSolvers algorithm reports ReturnCode.Default and successful_retcode is false, while KrylovJL reports Success on the same problem. That is pre-existing and I left it alone deliberately: the extension never checks convergence, so reporting Success unconditionally would claim something it has not verified, for example when a solve simply runs out of iterations. Happy to change it if you want that behaviour, but it seemed like its own decision rather than part of a bug fix.
• On Wrong solution when updating the rhs for iterative solvers #181 itself: the reported wrong answer no longer reproduces. That report used LinearSolve.set_b, which no longer exists; with the current cache API, updating cache.b and re-solving gives errors around 5e-18 for CG, GMRES and BICGSTAB. It can be closed as fixed independently of this PR.

Verification

• All five IterativeSolversJL_* variants solve correctly, bare and with tolerance kwargs, both on a fresh solve and after a b update through the cache: 10 of 10 combinations, previously 6.
• Full GROUP=Core suite passes with zero failures.
• Runic clean.

AI Disclosure: Used Opus 5