Expose spin-summed RKS setting through C/Fortran APIs

[DCM-Uni-Paderborn]

Dear David,

this is the follow-up to #208 for the skala branch. It assumes that the core C++ setting and host/device/shell-batched handling from #208 are accepted first, and only exposes that setting through the external APIs needed by downstream callers such as CP2K.

Changes in this PR are now limited to:

• C API GauXCKSSettings
• C API RKS entry points with explicit settings for EXC, EXC/VXC, EXC gradients, and FXC contraction
• Fortran API optional RKS settings wrappers
• a focused C API regression check for spin-summed closed-shell RKS density input

The core IntegratorSettingsKS extension, host/device/shell-batched RKS scaling, standalone-driver keyword, and C++ integrator regression are intentionally left to #208 and are no longer duplicated here.

This remains a draft until #208 is merged and the skala branch contains the agreed core convention.

Validation:

• checked git diff --check
• reduced the diff against skala to the C API, Fortran API, and C API test files only

Greetings,
Thomas

[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.