Fix RDKit 2025.09 compatibility for deprecated valence API

[evasnow1992]

RDKit 2025.09+ deprecates getExplicitValence()/getImplicitValence() in favor of getValence(ValenceType::EXPLICIT/IMPLICIT). The previous version guard (#if RDKIT_VERSION_NUM) was non-functional because RDKIT_VERSION_NUM is not defined in any RDKit version — the conda-forge librdkit-dev ships unsubstituted CMake template placeholders in versions.h.

Replace with SFINAE-based compile-time detection: checks if RDKit::Atom::ValenceType exists as a nested type. If present (2025+), uses the new API; if absent (2024), falls back to the old API with deprecation warnings suppressed via pragma. Zero runtime cost.

Also suppress deprecation warnings in test_molecules.cu for the same API calls used in test helper functions.

[greptile-apps]

Greptile Summary

This PR fixes RDKit 2025.09 compatibility by replacing a non-functional #if RDKIT_VERSION_NUM preprocessor guard (the macro is an unsubstituted CMake template placeholder in all RDKit releases) with a robust SFINAE-based compile-time detection mechanism. The new rdkit_compat.h header checks for RDKit::Atom::ValenceType and dispatches to either getValence(ValenceType::EXPLICIT/IMPLICIT) (2025.09+) or the deprecated getExplicitValence()/getImplicitValence() with suppressed warnings. The test helper is also updated to call the same compat wrappers, keeping it consistent with production code.

• src/utils/rdkit_compat.h (new): SFINAE dispatch via std::void_t<T::ValenceType> detection — clean, zero-runtime-cost, and C++20-compatible.
• src/substruct/molecules.cpp: Old broken version guard replaced with compat::getExplicitValence/getImplicitValence calls; the <RDGeneral/versions.h> include is now dead code and can be removed.
• tests/test_molecules.cu: Test helper updated to use the same compat wrappers, resolving the previously flagged forward-compatibility gap.

Confidence Score: 4/5

• This PR is safe to merge; it correctly fixes a real compilation issue with no logic changes to production behavior.
• The SFINAE approach is well-formed for C++20 and the dispatch is deterministic at compile time. The only finding is a now-unused #include <RDGeneral/versions.h> left over after removing the RDKIT_VERSION_NUM guard — a minor cleanup item that has no runtime impact.
• No files require special attention beyond the trivial stale include in src/substruct/molecules.cpp.

Important Files Changed

Filename	Overview
src/utils/rdkit_compat.h	New SFINAE compatibility header that correctly detects RDKit::Atom::ValenceType at compile time and dispatches to either the new getValence() API (2025.09+) or the deprecated getExplicitValence()/getImplicitValence() with suppressed warnings. Logic is sound for C++20.
src/substruct/molecules.cpp	Replaces the non-functional #if RDKIT_VERSION_NUM guard with calls to the new compat helpers. Minor: <RDGeneral/versions.h> is now an unused include since the only consumer (RDKIT_VERSION_NUM) was removed.
tests/test_molecules.cu	Test helper now calls nvMolKit::compat::getExplicitValence/getImplicitValence instead of the deprecated API directly, keeping the test consistent with production code and resolving the previous review thread's concern.

_{Last reviewed commit: 65a064d}

[scal444]

Since we switched to c++20, most things that SFINAE were used for are better represented with concepts. Like:

template <typename T>
concept HasValenceType = requires { typename T::ValenceType; };

Then in the implementation, it should be as simple as

if constexpr (HasValenceType<RDKit::Atom>) {
 // modern path
} else {
// legacy path
}