Select minor duplicate indices

[fishidaho]

Fix silent data loss when a minor-axis selection repeats an index

What's wrong

arr[:, [1, 1, 3]] returns zeros where column 1's second copy should be. Just wrong values, in a shape that looks right.

v[:, [1, 1, 3]] want got
[[ 2 2 4] [[ 0 2 4]
[ 6 6 8] [ 0 6 8]
[10 10 12]] [ 0 10 12]]

This is a regression introduced by #23. Before it, the same expression fell through to to_scipy()[...], and scipy fans duplicate fancy indices out correctly. Verified directly against 45ce15d, where it returns the right answer.

Duplicate indices aren't exotic here: any resampling-with-replacement, any bootstrap over cells or genes, any join that maps several output columns onto one source column produces them. The failure is silent, so it surfaces as a downstream result being subtly wrong rather than as a crash.

Why it isn't a small patch

The cause is structural. _select_minor builds one old → new lookup array:

remap=np.full(self.n_minor, -1, dtype=np.int64)
remap[idx] =np.arange(n_minor_new, dtype=np.int64)

A repeated index writes that slot twice and only its last destination survives. A single array can't express one-to-many, so no amount of care around this formulation fixes it.

The fix inverts the selection instead. fanout/offsets/positions give, for each original minor index, every output position it maps to; each stored element then emits one entry per destination.

It also removes an nnz-sized temporary

Deriving each major slice's slot count with np.searchsorted on major_ptr drops the np.repeat(np.arange(n_unique), ...) the old version needed, which was nnz-sized. Peak allocation for a 2e6-nonzero selection:

before 62.27 MB
after 4.78 MB (13x)