deps: bump cpu/cuda pins so the whole tree agrees on one kernels commit

[balbasty]

Top of a bottom-up cascade that closes a live submodule pin skew. Gitlink-only — git diff-tree reports exactly two modified paths, cpu and cuda.

• cpu: dbd3274 → 1fb2b37 (current fastfields-cpu-libmain)
• cuda: 6ae52bd → 2b2ad55 (current fastfields-cuda-libmain)

The skew

Traced by walking the actual gitlinks on main, not the submodule branch labels:

CPU path : lib -> cpu-lib dbd3274 -> cpu-impl 41d66b3 -> kernels be7be08
CUDA path: lib -> cuda-lib 6ae52bd -> cuda-impl a099a04 -> kernels b09b284

The two backends genuinely resolved to different kernels commits, CUDA three behind:

kernels PR	commit	what the CUDA path was missing
#74	32951da	heap over-read from the past-the-end FaceIterator — a memory-safety fix
#76	3e38c85	make the host BVH/normal builders visible to nvcc's host pass — a CUDA-specific fix the CUDA path itself lacked
#78	be7be08	drop the pointless virtual destructors from Node/BoundingSphere

Two details worth recording, both found by tracing rather than assuming:

1. The stale link was cuda-lib's impl pin, which was 11 commits behind cuda-implmain. cuda-impl's own main already pinned 3e38c85, so the CUDA path resolved to a third kernels commit that neither leaf repo pointed at directly.
2. The skew was one commit wider than described in either direction: #78 was missing too, and the CPU path was itself one behind kernels main (be7be08, predating tools: restore consolidate.sh onto the consolidated main #79).

Final state — all six repos on one kernels commit

lib -> cpu-lib 1fb2b37 -> cpu-impl 5e2c78e -> kernels 1df9fd3
lib -> cuda-lib 2b2ad55 -> cuda-impl 83fa026 -> kernels 1df9fd3

What the cascade carries

change	where
diag_bending/diag_all corner cross-term correctness fix (12 terms, 6 functions)	kernels#81 → both backends
its regression test (2D + 3D, whole-domain, 3 boundary conditions)	cpu-lib#89
reg_flow bending==0 Lamé dispatch routing	cpu-lib#87
eight missing #pragma once include guards	cuda-impl#48
restrict.h → batch.h include for index2sub (unblocks g++ entirely)	kernels#79, via both pins

Verification

• CPU suite at the final chain: 13/13 suites, 0 failures (test_reg_field 19250 checks, test_reg_flow 16347, both including the new regression tests).
• The fix is genuinely exercised: the new tests fail with 328 + 1696 failures against pre-fix kernels and pass at 1df9fd3, with identical check counts both ways.
• g++: full clean build + suite run, exit 0, 13/13 green — previously impossible on this tree.
• CUDA compile+link: build-via-cuda-lib passed on cuda-impl#48 (5c68cf9) and cuda-impl#49 (83fa026), and cuda-lib#47's own build job passed at 2b2ad55 — each a real make -C . -j2 CXX=clang++ CXXFLAGS="-std=c++14 -O1". -O1 and the split MODULES list are untouched.

Pin hygiene

Both pins are the squash-merge commits on their repos' main, not pre-merge branch heads. Every gitlink in the chain was verified to resolve with git cat-file -e before opening this PR — the check caught one stale local view, which was a missing fetch rather than a dangling pin.

🤖 Generated with Claude Code

https://claude.ai/code/session_016AjQcY78NgbagPSbPJRr6Z

---

Generated by Claude Code

[github-actions]

Submodule staleness (non-blocking -- fastfields-lib#15)

submodule	pinned commit	tracks	status	behind by
cpu	1fb2b37	fastfields/fastfields-cpu-lib@main	up to date	0
cuda	2b2ad55	fastfields/fastfields-cuda-lib@main	up to date	0