Mark matrix-free composites as non-concretizable

[AshtonSBradley]

Summary

Extends the existing has_concretization trait through SciMLOperator wrappers and composites so matrix-free operators are not accidentally treated as materializable matrices.

Compositions involving matrix-free FunctionOperators now report has_concretization == false, while matrix-backed/scalar-backed wrappers continue to report true recursively.

Motivation

Downstream packages such as OrdinaryDiffEq need to know whether an operator can be safely converted to an AbstractMatrix. Without this, matrix-free compositions such as FunctionOperator \ DiagonalOperator * FunctionOperator can reach convert(AbstractMatrix, ...) and fail.

This is the first PR in a pair for SciML/OrdinaryDiffEq.jl#2078.

Paired OrdinaryDiffEq PR: SciML/OrdinaryDiffEq.jl#3588

Changes

• Add recursive has_concretization methods for scalar operators, wrappers, composites, tensor products, and InvertibleOperator.
• Mark common concrete inputs as concretizable.
• Make generic matrix predicates return false for non-concretizable operators instead of falling through to concretization.
• Add regression tests for matrix-backed and matrix-free composites.

Type stability / allocations

This is trait-only dispatch. It avoids eager matrix materialization for matrix-free operators and does not introduce per-application allocation. Existing concrete conversion behavior is preserved for matrix-backed operators.

Tests

julia --project=. -e 'using Pkg; Pkg.test()'

[AshtonSBradley]

Codex was used to help prepare and validate this PR.