Add sklearn.cluster.HDBSCAN acceleration to cuml.accel

[viclafargue]

Closes #7522.

Adds a dedicated cuml.accel proxy for sklearn.cluster.HDBSCAN, backed by cuML’s GPU implementation while keeping the existing hdbscan.HDBSCAN integration unchanged.

The new adapter translates parameters and fitted state, supports dbscan_clustering after GPU fitting, preserves the originating scikit-learn interface during serialization, and falls back to scikit-learn for unsupported parameters or inputs. It also enforces C-contiguous HDBSCAN input to correctly handle pandas DataFrames.

Includes integration, CPU/GPU interoperability, serialization, fallback, and upstream compatibility coverage, with documentation of expected numerical differences.

[csadorf]

Nice work! Please address the min_samples semantic mismatch and my other comments. Otherwise, this looks good to me.

[csadorf]

That's a very small number of new xfails -- nice!

[csadorf]

Is this fixing a pre-existing issue with Fortran-contiguous input? check_inputs otherwise preserves the input order, while HDBSCAN expects C-major input. If so, could we add a focused regression test?

[csadorf]

From my understanding, forwarding this value unchanged is incorrect. runner.h increments min_samples before native execution to match the contrib convention:

cuml/cpp/src/hdbscan/runner.h

Line 79 in 7424d70

linkage_params.min_samples = params.min_samples + 1;

On this branch, sklearn with k=5 versus cuml.accel with k=5 gives an ARI of 0.0, while using k=4 on the accelerated estimator raises it to 0.864. Independently, sklearn k matches contrib k-1 exactly.

Could we translate the semantics in the sklearn adapter, handle the min_samples=1 boundary explicitly, and add a boundary-sensitive regression test? The current parameter-translation test appears to codify the unchanged forwarding.