Decouple PDMat's matrix and Cholesky factor types (#237)

[devmotion]

Note

Builds on #239 (now merged). This PR was stacked on top of it and has been retargeted to master, so the diff shown here is only this PR's own changes.

Why #239 was necessary: decoupling the matrix from the Cholesky factor type means PDMat now propagates the matrix's own type — e.g. a Symmetric wrapper — into .mat, instead of densifying it to a plain Matrix. Addition then forwards .mat straight into _adddiag (e.g. +(a::PDMat, b::PDiagMat) = PDMat(_adddiag(a.mat, b.diag))), which previously was only defined for Union{Matrix, SparseMatrixCSC} and would now hit a MethodError. #239 generalized _adddiag/_scaleadddiag to any AbstractMatrix, so this PR relies on it to keep +/pdadd working for the newly-preserved wrapper types.

Closes #237.

Problem

PDMat{T, S} forced the stored matrix mat::S and its Cholesky factorization chol::Cholesky{T, S} to share one array type S. Constructing a PDMat from a dense matrix and a Cholesky whose factors have a different array type therefore failed, because the matrix was coerced to the factor type:

julia> PDMat(mat, chol)   # chol.factors isa Fill
ERROR: Input array contains both 0.0 and 2.0. Cannot convert to Fill

This broke dense MvNormal/PDMat construction over covariances produced by SparseConnectivityTracer (≥ 1.2.2), which returns Cholesky{T, <:Fill}.

Change

Add a third type parameter C <: Cholesky{T} so the factorization's storage type is independent of the matrix's:

struct PDMat{T <: Real, S <: AbstractMatrix{T}, C <: Cholesky{T}} <: AbstractPDMat{T}
    mat::S
    chol::C
end

The two-argument constructor keeps both arguments as-is when their element types match (a fast path that preserves identity, isbits-ness, and allocation behavior) and promotes them otherwise — instead of the previous lossy "take the element type from chol" coercion.

PDMat{T, S} and PDMat{T} remain valid partial (UnionAll) types, so existing dispatch, construction, conversion, and the deprecations continue to work unchanged.

Behavior change

Because the matrix is no longer coerced to the factor type, PDMat now keeps the matrix's own type. For example PDMat(Symmetric(A)) keeps the Symmetric wrapper (the data is not densified), where previously .mat was the bare underlying matrix. The specialarrays.jl banded-matrix test is updated accordingly.

Tests / misc

• Regression test pairing a dense matrix with a Fill-factored Cholesky, looping over mat/chol element-type combinations across PDMat, PDMat{T}, and PDMat{T, S}. FillArrays is added as a test dependency.
• Refreshed a stale doctest repr in generics.jl.

Full test suite passes locally.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.66%. Comparing base (eab0192) to head (676b5be).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #238      +/-   ##
==========================================
- Coverage   94.84%   94.66%   -0.18%     
==========================================
  Files          11       11              
  Lines         814      825      +11     
==========================================
+ Hits          772      781       +9     
- Misses         42       44       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[devmotion]

I think this PR is ready for review now.

IMO the remaining 3 test failures in the Distributions tests are not practically relevant, they test whether some dense MvNormal distributions are subtypes of the FullMvNormal type aliases which relies on the type parameters of PDMat which arguably are not public API. This doesn't seem to affect anything in practice though apart from less compact printing: https://github.com/search?q=repo%3AJuliaStats%2FDistributions.jl+FullNormal&type=code

[andreasnoack]

Wouldn't it be better to adjust the Distributions tests first to avoid breaking CI there?

[devmotion]

Initially I thought it wouldn't be possible (unless we'd remove the tests) but I got an idea, let me check it.

[devmotion]

CI shows that the Distributions downstream tests in this PR pass with JuliaStats/Distributions.jl#2073 (for which Distributions tests with the latest PDMats release pass as well)