ROCm deltaspin force/stress kernels still use the pre-#8122 Pauli-y signs #8133

Going through the deltaspin kernels after #8125 landed, I noticed the two ROCm copies never picked
up the Pauli-y fix:

source_pw/module_pwdft/kernels/rocm/force_op.hip.cu:416-417
source_pw/module_pwdft/kernels/rocm/stress_op.hip.cu:1022-1023

Both still use coefficients1 = (lambda_x, +lambda_y) / coefficients2 = (lambda_x, -lambda_y),
whereas the CPU and CUDA versions have them the other way round since #8122/#8125. The rest of the
contraction is the same in both files - same index arithmetic, same dbb0..dbb3, same 2*tpiba
factor, same lambda_z on the diagonal - so as far as I can work out the net effect is that the
kernel applies L^T instead of L = lambda.sigma, which flips the sign of the lambda_y term in
force and stress and leaves lambda_x / lambda_z alone. I'd expect that to show up as wrong
forces for a USE_ROCM + nspin 4 run with a nonzero target y moment, but I have no AMD machine
to test on, so I can't confirm it numerically.

rocm/force_op.hip.cu and rocm/stress_op.hip.cu are both in hip_add_library(device_rocm ...) at
source/CMakeLists.txt:671, and there's no hipify step anywhere in the build, so these really are
hand-maintained duplicates that the two fixes just missed. #8125 says ROCm was out of scope, so
maybe this is a known gap - apologies if so.

The reason I think it keeps coming back is that the lambda -> spinor map is open-coded in about six
places, and they use two different orderings for the same 4-element array: {uu, ud, du, dd} in
mi_tools.h:34 (pauli_vector_to_spinor, which only dspin_lcao.cpp:63 actually calls) versus
{uu, du, ud, dd} in deltaspin_pw_mi.cpp:181 and op_pw_proj.cpp:165. Each one is fine as long
as the consumer reads the matching index, which is nothing but implicit - and it seems to be why
#7513 / #7664 / #7832 / #7914 / #8117 / #8122 / #8125 each turned up one more copy that had fallen
behind. Worth adding that the existing tests wouldn't have caught most of these: the cases that set
a transverse moment (tests/17_DS_DFTU/*_XYZ) are SCF-only - none of the 47 enable cal_force or
cal_stress - and the two cases that do compute force and stress only got nonzero lambda_y on
10-12.

Would a small PR that just syncs the two .hip.cu files be useful? Separately, is there any appetite
for routing all of these through pauli_vector_to_spinor and pinning the convention with a unit test
against an explicitly constructed spinor pointing out of the x-z plane - the current
<psi|lambda.sigma|psi> = lambda.M check takes both sides from the same convention, so it looks like
it would pass even if the whole convention were flipped.