`lstsq(alg=:iterative)` blanket-rejects non-BLAS eltypes, yet the iterative engine works in BigFloat

WHAT: _check_lstsq_eltype (src/lstsq.jl:30-41) is called by all three engines, including iterative (ext/...IterativeSolversExt.jl:22). But the iterative engine uses only the structured matvec/adjoint + IterativeSolvers.lsqr/lsmr — none need BLAS floats. Confirmed: a rank-deficient BigFloat A via lsqr converged to relerr 1.6e-15 vs the pinv oracle, yet lstsq(A, b; alg=:iterative) throws ArgumentError. WHY IT MATTERS: A real capability is needlessly suppressed — high-precision Newton in BVP solvers is the package's target regime. The guard is correct for :dense (LAPACK gelsy) but wrong for :iterative. FIX: Move the BLAS-float guard out of the shared entry into the dense/structured paths only; in the iterative engine check for real/complex AbstractFloat (still rejects Int/Rational, lets BigFloat/Complex{BigFloat}/Float16 through). Add the Int-rejection test plus a BigFloat iterative test. Update the docstring/README ('Only Float32/Float64/...'). Pairs with documenting that :structured/:dense are BLAS-float-only by design (the :structured SVD needs GenericLinearAlgebra) and directing generic-eltype users to :iterative. EFFORT: S.

Priority: medium. Filed from an automated next-steps audit of the QR/lstsq work (see PR #6).

Start with _check_lstsq_eltype in src/lstsq.jl:30-41 and the iterative entry point in ext/...IterativeSolversExt.jl:22; compare how the three engines apply the guard. Add the requested Int-rejection and BigFloat iterative tests, then update the docstring/README so the BLAS-only limitation is clear for :dense and :structured; done means iterative BigFloat works while unsupported integer inputs remain rejected.