[cuda] implement basic monotone constraint enforcement on the CUDA tree learner

[maxwbuckley]

Problem: the delta

When training with device_type="cuda", monotone_constraints was silently ignored. The CUDA best-split finder and CUDALeafSplits had no constraint plumbing — unlike the CPU FeatureHistogram, which clamps child outputs into the leaf's [min, max] constraint range and rejects monotonicity-violating splits.

Measured delta before this PR (600×3 regression, monotone_constraints_method="basic", gpu_use_dp=true; violations counted on 4,500 grid points per config — 3 base points × 500-point sweeps × constrained features):

constraints	rounds	CPU violations	CUDA violations	CUDA worst violation	max pred delta vs CPU
[1, −1, 0]	30	0	9	3.0e-02	0.52
[1, −1, 0]	100	0	203	1.1e-01	0.32
[1, 1, 1]	30	0	157	3.9e-01	2.76
[1, 1, 1]	100	0	456	3.9e-01	2.81
[−1, 0, 1]	30	0	157	7.0e-01	2.82
[−1, 0, 1]	100	0	389	6.9e-01	3.14

A user requesting monotone constraints on CUDA got a model that violates the requested relationship at hundreds of points — silently. For regulatory/safety uses of monotonicity this is a hard correctness failure.

Fix

Implements the basic monotone constraint method on the CUDA tree learner:

• CalculateSplittedLeafOutputMC / GetSplitGainsMC device functions mirror the CPU USE_MC formulas: candidate child outputs are clamped into the leaf's [min, max] constraint range, and splits whose clamped outputs violate the monotone direction are rejected (gain 0).
• Each SplitFindTask carries its feature's monotone type (config is real-feature-indexed; mapped to inner indices, matching the CPU FeatureMetainfo setup).
• Per-leaf [min, max] constraint ranges are tracked on host — mirroring BasicLeafConstraints::Update midpoint propagation — and passed to the split kernels for the (smaller, larger) leaf pair each iteration.
• Leaf values stored in CUDASplitInfo are the clamped outputs (used for the tree and constraint propagation); leaf gains keep their unconstrained values (they form the child's parent_gain baseline, matching CPU's BeforeNumerical gain-shift computation). Getting this distinction wrong was the prototype's main bug.
• Unsupported monotone configurations fail fast with a clear error: monotone_constraints_method=intermediate/advanced, monotone_penalty>0, and use_quantized_grad + monotone.

This replaces the first commit's Log::Fatal guard: basic-method monotone constraints now work on CUDA.

Result: the delta after the fix

Same measurement, post-fix — across all constraint vectors × {1, 30, 100} rounds × 2 seeds:

constraints	rounds	CUDA violations	CUDA training MSE	CPU training MSE
[1, −1, 0]	30 / 100	0	0.0643 / 0.0122	0.0658 / 0.0129
[1, 1, 1]	30 / 100	0	1.953 / 1.947	1.957 / 1.952
[−1, 0, 1]	30 / 100	0	1.449 / 1.206	1.438 / 1.241
[0, 0, 0] (inactive)	30 / 100	0	bit-identical to CPU (≤ 8.9e-16)	—

Zero monotonicity violations in every configuration (24/24 test configs), with constrained training quality equivalent to CPU (MSE within 3%, often slightly better) and bit-exact parity when constraints are inactive.

Honest scope note: structure parity vs. constraint parity

CPU and CUDA can build different but equally valid constrained trees in multi-round training. The cause: CPU prunes candidate features through its FeatureHistogram::is_splittable_ cache (a feature found unsplittable on a parent is skipped for the whole subtree — a search-space heuristic, not part of the constraint definition). Replicating that cache on GPU requires per-(leaf, feature) state with extra host-device round trips; an experimental version made agreement worse because the cache semantics interact with histogram-subtraction timing. So this PR guarantees the property (zero violations + equivalent quality + bit-parity in the inactive case), not node-by-node tree equality. The PR description and tests state exactly that.

Tests (in test_dual.py, gated on TASK=cuda)

Test	Cases	What it pins down
test_cuda_monotone_constraints_are_enforced	12	zero violations on 4,500-point grids — fails on the old build (up to 456 violations)
test_cuda_monotone_constraints_match_cpu_quality	3	both backends enforce + CUDA MSE within 5% of CPU
test_cuda_monotone_noop_constraints_match_cpu_exactly	2	all-zero constraints → bit-exact CPU parity (atol=1e-10)
test_cuda_monotone_unsupported_configs_raise	1	intermediate/advanced/penalty/quantized configs rejected loudly

Full test_dual.py suite (72 tests) passes.

🤖 Generated with Claude Code

[BelixRogner]

Thank you, Max — and thank you, Claude Code (independently 🙂). This one's a clean bill of health.

I ran a deep correctness review of the device math against the CPU USE_MC path in feature_histogram.hpp and BasicLeafConstraints::Update. Verdict: SOLID, no blocking issues.

• CalculateSplittedLeafOutputMC / GetSplitGainsMC match the CPU clamp + rejection predicate character-for-character ((mc>0 && left>right) || (mc<0 && left<right) → gain 0).
• The delicate part — leaf VALUE clamped vs leaf GAIN unconstrained — is correct. Verified the stored left_gain/right_gain flow into cuda_data_partition.cu as the next level's parent_gain baseline, exactly like CPU's BeforeNumerical. Using clamped outputs there would have inflated child gains; you got it right.
• Host UpdateLeafConstraints mirrors the midpoint propagation (UpdateMin/UpdateMax, parent/new-leaf roles) correctly.
• All three scope guards (intermediate/advanced, monotone_penalty>0, use_quantized_grad) are unconditional Log::Fatal — no silent fall-through — and all tested.

Non-blocking note: path_smooth>0 and lambda_l1>0 combined with monotone aren't exercised by the new tests; the formulas are shared with the already-tested non-MC paths, so low risk.

Only thing standing between this and merge: it fails the required ruff format check, and since all five of your CUDA PRs touch the same files, it'll need a git merge master once the others land. The macOS CI red is the known dask socket flake — unrelated.

P.S. — you wrote a 4,500-point monotonicity grid harness with bit-exact CPU parity… and then didn't run ruff format? 😄 All five PRs tripped it. Exa-row scale, zero-row lint discipline.