NonlinearSolveAlg: extend W-reuse to WOperator with concrete underlying Jacobian

[singhharsh1708]

Closes #3697 for the common case.

Summary

`build_nlsolver` previously gated `use_w_reuse` on
```julia
W isa AbstractMatrix && !(W isa AbstractSciMLOperator)
```
which excluded `WOperator` entirely. But a `WOperator` built around a concrete Jacobian (the typical setup when the user picks an iterative linsolve such as `KrylovJL_GMRES` with `concrete_jac = true`) carries the materialized `M/γdt - J` in its `_concrete_form` field, and `_update_nlsolvealg_W!` already writes the refreshed W there via `jacobian2W!`. We can hand that buffer to NonlinearSolve as the analytic Jacobian unchanged.

Truly matrix-free `WOperator`s (where `W.J` is itself an `AbstractSciMLOperator`) still fall back to AD/FD on the inner Newton — handing those off as analytic Jacobians is a deeper change tracked separately.

Measured

Robertson, `linsolve = KrylovJL_GMRES(), concrete_jac = true`, `nlsolve = NonlinearSolveAlg(NewtonRaphson(autodiff = AutoFiniteDiff()))`:

Solver	steps before	steps after	nf before	nf after
TRBDF2	532	394 (−26%)	8808	8416 (−4%)
FBDF	1198	479 (−60%)	23934	10542 (−56%)
KenCarp4	533	371 (−30%)	12975	9923 (−23%)

Audit

• Default (concrete) linsolve paths: byte-identical to master (no regression)
• Matrix-free WOperator path (e.g. `KrylovJL_GMRES` without `concrete_jac=true`): correctly excluded by the new gate
• `nested_ad_nlsolvealg_tests.jl`: 5/5 pass
• Runic-clean