fix(placement): label-encode classification targets for LightGBM

[ChrisW09]

Fixes #61.

With placement_strategy="lightgbm" and task="classification", target-aware placement handled only targets coded with one class ≤ 0 and the other > 0. For labels such as {1, 2} it silently fell back to quantiles, for multiclass targets it found only the class-0 boundary, and for string labels fit raised. This affected PLE, the feature maps and the knot splines.

Root cause

LightGBMLocationSelector._ordered_candidates set objective="binary" for every classification task and passed the raw labels to lgb.Dataset. LightGBM's binary objective needs numeric labels and treats every label > 0 as positive. There was no label encoding and no multiclass objective. When no split was found, select fell back to quantile locations without a warning.

Fix

In LightGBMLocationSelector._ordered_candidates, a classification target is label-encoded with np.unique(y_valid, return_inverse=True) and the objective follows the number of classes:

• two classes: binary (binary_logloss);
• more than two: multiclass with num_class (multi_logloss);
• a single class has no split to learn: the method returns no candidates, and select takes its unsupervised fallback.

Regression is unchanged.

Behaviour changes

• LightGBM placement with task="classification" now follows the class boundaries for labels other than {0, 1}, for multiclass targets and for string labels. In the issue's example, the {1, 2} target gets [0.901 0.972] instead of the quantiles [0.367 0.685], the three-class target gets [0.094 0.901], and string labels no longer raise.
• {0, 1} targets are unaffected: their codes equal the labels.
• A single-class classification target with string labels now takes the unsupervised fallback instead of raising.

Documentation

• LightGBMLocationSelector class docstring: new paragraph on the classification handling (label encoding, so any class labels work as with the CART selector; binary for two classes, multiclass for more; a single class falls back to unsupervised locations).
• No docs page changes: docs/core_concepts/resolution_and_placement.md presents "lightgbm" as an alternative to "cart" with no restriction on the labels, which now holds.

Tests

• test_lightgbm_classification_places_a_location_at_the_class_boundary[labels-1-2, three-classes, string-labels]: a location lies within 0.01 of the class boundary at 0.9. Fails on main, passes here.
• test_lightgbm_classification_with_a_single_class_falls_back: a single-class string target returns the unsupervised fallback [1/3, 2/3] on linspace(0, 1, 200). Fails on main (ValueError: could not convert string to float), passes here.

Reproduction

Output of the script from #61 on this branch (LeakageWarnings omitted):

quantile_knots: [0.367 0.685]
labels {1,2}, boundary 0.9       cart      [0.367 0.901]
labels {1,2}, boundary 0.9       lightgbm  [0.901 0.972]
3 classes, boundaries 0.1/0.9    cart      [0.1   0.901]
3 classes, boundaries 0.1/0.9    lightgbm  [0.094 0.901]
string labels                    cart      [0.367 0.901]
string labels                    lightgbm  [0.901 0.972]

Checks

• just test: 1442 passed, 59 skipped, 7 xfailed; coverage 93.67% (gate 90%).
• Minimum dependencies (CI job: Python 3.10, numpy 1.24.4, pandas 2.0.3, scipy 1.10.1, scikit-learn 1.6.0): 1425 passed, 76 skipped, 7 xfailed; scripts/quickstart.py passes. The new tests skip there because lightgbm is not installed.
• just docs: strict build succeeds.
• just check: all pre-commit and pre-push hooks pass (ruff format, ruff lint, prettier, file hygiene, pyright with 0 errors).
• Import direction between subpackages is unchanged.

Merge notes

• Base: main.
• The PRs for CART location selector can drop the dominant split because spacing is enforced in ascending location order #70 (fix(placement): rank CART splits by impurity decrease before spacing #110) and Target-aware location selectors return too few, duplicate, or boundary locations on tied/discrete features #57 (fix(placement): fill tied-data locations with distinct interior points #102) also change pretab/core/selectors.py, but in other functions, and the code merges cleanly. All three append tests at the end of tests/core/test_location_selectors.py, so whichever lands later gets an append/append conflict there: keep both blocks. With Target-aware location selectors return too few, duplicate, or boundary locations on tied/discrete features #57, the single-class fallback goes through its new _supplement, which returns the same [1/3, 2/3] for this PR's test. With all three branches combined, the full test suite passes (1478 passed, 59 skipped, 7 xfailed).
• The PR for An invalid task such as "Regression" is silently treated as classification by the splines and selectors #93 (fix(validation): reject an unknown task instead of using classification #128) conflicts in the params dict of LightGBMLocationSelector._ordered_candidates. An invalid task such as "Regression" is silently treated as classification by the splines and selectors #93 rewrites the objective/metric lines, and this PR replaces those same lines with **objective. Keep this PR's **objective. Once An invalid task such as "Regression" is silently treated as classification by the splines and selectors #93 validates task in select, the else branch here only ever sees "classification".
• With the PR for RepresentationSearchCV with a classifier uses task="regression" for placement; string labels crash #77 (fix(search): default to the classification task for a classifier #115), a RepresentationSearchCV around a classifier passes task="classification" to its preprocessors. String labels with preprocessor_params={"placement_strategy": "lightgbm"} work only once this PR is merged as well.

This change was previously part of #75, which is closed in favour of one pull request per issue.