Expose spin-summed RKS density matrix setting

[DCM-Uni-Paderborn]

Dear David,

this adds an explicit RKS density-matrix convention setting for Kohn-Sham XC integrations.

By default, GauXC keeps the existing convention and interprets an RKS density matrix as a one-spin density. Some external interfaces, however, naturally provide the closed-shell spin-summed RKS density. Those callers currently need downstream patches that alter the internal RKS density prefactor globally.

This PR adds an opt-in setting:

• IntegratorSettingsKS::rks_density_matrix_is_spin_summed
• matching C API settings
• matching Fortran API optional settings
• propagation through host, device, and shell-batched paths
• a standalone-driver keyword for HDF5/reproducer workflows
• a C API regression test using a spin-summed RKS density

The default behavior is unchanged. Callers that pass spin-summed closed-shell RKS densities can now request the corresponding convention explicitly.

Validation:

• built the host/HDF5 standalone driver
• built the Fortran API libgauxc.a target
• checked git diff --check
• validated a CP2K-generated H2O all-electron GAPW/QZVPP HDF5 reproducer: with the spin-summed setting enabled, GauXC integrates about 10 electrons and gives the same EXC/gradient result as the equivalent one-spin-density input

Representative reproducer values:

• N_EL = 9.999998605222
• EXC = -9.247398490121
• EXC gradient rows:
  • 4.093212e-13 6.161044e-14 -4.648139e-01
  • -1.646329e-13 3.214351e-01 2.324069e-01
  • -2.447635e-13 -3.214351e-01 2.324069e-01

[awvwgk]

Can we separate the changes to the Skala implementation and core GauXC? The extension of the settings struct is a potential API change for the core library that is unrelated to Skala and is better discussed independently of the changes necessary to expose the new setting to the Fortran API for Skala.

[DCM-Uni-Paderborn]

Dear Sebastian,

Yes, that makes sense. I split off the core GauXC part into #208 against master. That PR only adds the C++ setting and the corresponding host/device/shell-batched RKS handling, plus a focused C++ regression check; it does not include Skala, OneDFT, C API, or Fortran API exposure.

I will keep this skala-branch PR as draft and rework/rebase it after the core convention is settled, so the follow-up here only exposes the agreed setting through the Skala/Fortran-facing API needed by CP2K.

Thanks for pointing this out.