fix(lammps): expose Kokkos pair style through plugin

[njzjz-bot]

Summary

• register deepmd/kk and deepmd/kk/device from the dynamic LAMMPS plugin when it is built with DEEPMD_LAMMPS_KOKKOS=ON
• expose DP_ENABLE_LAMMPS_KOKKOS=1 through the Python build backend so wheel builds can request the existing CMake option
• compile the plugin target through Kokkos's downstream compiler launcher when Kokkos support is enabled
• reject the build-backend toggle when no LAMMPS plugin version is selected
• add focused tests for the Python build-backend toggle

Why

The Kokkos pair style is already implemented and the plugin CMake target already has a DEEPMD_LAMMPS_KOKKOS option, but deepmdplugin.cpp currently does not register the Kokkos pair style. As a result, compiling those sources into the module is not sufficient for pair_style deepmd/kk to become available through the dynamic plugin.

This PR provides the prerequisite wiring needed before enabling Kokkos in PyPI wheel builds.

PyPI / CUDA architecture investigation

The requested distribution target was a small representative CUDA set (sm_70, sm_89, sm_120 plus a compute_80 PTX fallback). I did not turn that set on in the release wheel in this PR because the current packaging stack needs additional coordination with the PyPI LAMMPS host:

1. Kokkos rejects multiple configured GPU architectures in one build, so a Kokkos/LAMMPS build cannot be configured as VOLTA70 + ADA89 + BLACKWELL120 in the same way as an ordinary CUDA fatbin.
2. DeePMD-kit currently fetches stable_22Jul2025_update2 for the wheel plugin headers, and the current PyPI lammps wheel uses stable_22Jul2025_update4; both LAMMPS releases bundle Kokkos 4.6.02. Native BLACKWELL120 support was added in Kokkos 4.7. A newer external Kokkos could be evaluated, but the LAMMPS host and plugin must use a compatible configuration together.
3. The current PyPI lammps wheel is not built with PKG_KOKKOS. Enabling only the DeePMD plugin side would therefore produce a wheel that installs but cannot safely run deepmd/kk with the default PyPI LAMMPS host.

A safe packaging follow-up is to make the PyPI LAMMPS host Kokkos-enabled with the same Kokkos toolchain as the DeePMD plugin, then determine whether a supported fat-binary strategy is viable or whether matched architecture variants are required. The desired native targets remain Volta70, Ada89 (including RTX 4090), and Blackwell120, with compute_80 PTX considered as a forward-compatibility fallback rather than a substitute for Kokkos's architecture configuration.

Validation

• added focused tests for DP_ENABLE_LAMMPS_KOKKOS
• inspected the dynamic plugin registration path and Kokkos pair-style instantiations
• inspected the PyPI wheel build backend and LAMMPS wheel packaging path
• verified that Kokkos 4.6.02 exports kokkos_compilation(TARGET ...) for downstream CUDA compilation
• full Kokkos wheel compilation is not exercised by the existing release-wheel CI yet because no matching Kokkos-enabled PyPI LAMMPS host is currently supplied

Agent: ChatGPT
Model: GPT-5.6 Sol