Clone what the caller asks for, not the rest of the node

[pathscale]

range(k..=k).next() cost 212 ns, against 81 ns on 0.0.6. Reported as a
2.6x regression to be undone. It is not one, and the distinction decides what
the fix can be.

0.0.6 is not a valid baseline

It was fast because it was unsound. Its iterator was type Item = &'a T,
produced by transmute::<slice::Iter<'_, T>, slice::Iter<'a, T>> on an iterator
borrowed from a node's mutex guard: a yielded reference outlived the guard the
moment the scan advanced past that node, so iter().collect::<Vec<&T>>() read
storage nothing was holding.

Both steps since were correctness fixes, not regressions:

step	cost	bought
0.0.6 → 0.0.7	+41%	4052a1d, atomic select-and-lock, closing a split-migration window that silently truncated scans
0.0.7 → 0.0.8	+97%	1ef3098, owned clones instead of transmuted borrows, closing a use-after-free

So there is no route back to 81 ns that keeps the iterator sound, and no reason
to want one.

What was actually avoidable

Owned values are what soundness requires. Cloning a node's entire remainder
to produce one of them is not, and that is what install_front_batch did:

let batch = guard.iter().skip(skip).cloned().collect::<Vec<_>>();

A one-element range cloned every remaining element of whichever node it landed
in, then discarded all but the first.

The batch now starts at four and doubles per install, bounded by what the node
holds. A one-element range clones four; a long scan reaches whole-node batches
after a handful of installs and pays the same total clone count it always did.

range(k..=k).next()   212.1 ns -> 117.1 ns   (1.81x)
lookup_for_select      48.6 ns ->  40.9 ns   (untouched path, shown as a control)

That recovers the whole 1ef3098 step. What remains is 4052a1d, a
different change and not touched here. Restated honestly: this was never a 2.6x
regression against a valid baseline, it was 1.81x of avoidable waste on top of
a legitimate correctness cost, and the waste is gone.

Correctness of a partial batch

A batch that stops short of a node's end must resume inside that node rather
than step past it, so exhausted_*_node is set only when the batch reached the
end, and the count already taken is recorded so a resume can never take less
than it already has.

Six new tests cover the paths a whole-node batch could not reach, because it
never resumed inside a node: scans across many installs forwards and backwards,
a scan confined to a single node, ranges of every width across the batch
boundaries, single-element ranges, and a double-ended scan that must remain a
partition.

They were checked against broken code. Marking a node exhausted when the batch
stopped short fails six tests, two of which predate this change.

One thing deliberately unproven

The recorded take count also guards a concurrent stall: a repositioned node can
rank the cursor below elements already yielded, the yield path drops the batch
as duplicates, and the next install computes the same skip forever.

Removing that guard leaves the whole suite green, including
a_scan_under_concurrent_mutation_terminates, which was written to reach it and
does not. It is kept as insurance against a non-terminating scan, which is the
worst failure this iterator can have, and it costs one max. The code says it
is unproven rather than claiming coverage. If you can build the interleaving
that needs it, that test is worth more than the comment.

Second commit: the documentation compiles again

104 of 107 doctests had been failing since the crate was renamed. They say
use indexset::.., which is how every consumer refers to this crate
(indexset = { package = "WorkTablesIndex", .. }), but with no [lib] section
the library took the package's name and indexset resolved to nothing inside
the crate.

[lib] name = "indexset" restores the identity the fork was published with.
Consumers that rename are unaffected, which is all of them. The benches had
drifted the other way and imported WorkTablesIndex::, so the repository
disagreed with itself about its own name; they now match.

Three doctests failed for a real reason rather than the rename and are corrected
rather than deleted: remove takes both arguments by reference while the
examples passed them by value, and iter yields owned values since the
borrow-transmuting iterator was removed, so there was nothing left to
dereference.

107 of 107 pass. 110 unit tests pass, clippy -D warnings and cargo fmt
are clean.

Note on upstream

indexset 0.15.0 upstream still carries the same type Item = &'a T plus
transmute pattern this fork removed in 0.0.8, verified by inspection. WorkTable
depends on it directly as vanilla_indexset and exposes it as the using indexset backend.

I could not turn that into a demonstrated bug in our code: WorkTable's
range_values clones each item as it is yielded, before the iterator advances
and drops that node's guard, so it never holds a reference across a node
boundary. Treat it as a footgun in the upstream API rather than a live defect
here, and note that a Miri run aborts on an unrelated pre-existing
crossbeam-skiplist violation before it can reach the question.