perf(train): select top-k in the trainers instead of ordering everything

[ArthurZucker]

Three sites ordered a whole collection to consume a prefix of it. select_nth_unstable
answers that in O(n). 6.7–8.2× on WordLevel training with a million distinct words.
Output byte-identical.

Measured

cargo run --release --example topk -- 200000,1000000 3 8, interleaved base/new,
minimum over passes. feed is outside the timer — only the ordering is measured.

n distinct words	all counts equal	8 distinct counts
200,000	3.58×	3.84×
1,000,000	6.69×	8.17×

(1M distinct: 131 ms → 20 ms.) The speedup grows with n/k, which is what an
O(n log n) → O(n) change should do. Tie density barely matters — the cost is the number
of comparisons, not the price of each one.

The three sites

wordlevel.rs collected every entry of word_counts — one per distinct word in the
corpus, commonly millions — ordered all of them, and took the first vocab_size
(default 30_000). The min_frequency filter also moves ahead of the selection: its
predicate is on the count, which is the ordering's primary key, so it commutes with the
sort and shrinks n first.

unigram.rs make_seed_sentence_pieces ordered one entry per distinct substring of
the flattened corpus to consume seed_size (default 1_000_000) of them. The key is
(score, &[char]), so ties compare character slices rather than integers.

unigram.rs prune_sentence_pieces ordered every candidate to take pruned_size,
once per EM iteration, so the saving repeats.

Why the output is unchanged

Each site's comparator is a total order, so "select then order k" picks the same set in
the same order as "order everything":

• wordlevel: counts tie-break on the word, and words are unique (map keys).
• seed pieces: substrings are distinct; and two entries equal on both fields would push
  identical (string, score) pairs anyway.
• prune: this one needed work. The sort was sort_by — stable — and candidates is
  built by walking ids ascending, so equal losses already resolved by id. by_loss_then_id
  spells that out, which is what makes a selection equivalent. Its == bound also means
  an already-oversized new_pieces takes every candidate; that path keeps the full sort
  rather than quietly changing what it selects.

Both wanted computations mirror their loops exactly, including the seed loop's
off-by-one: its length check runs after the push, so a list already at seed_size
still takes one entry.

Tests

Neither unigram branch had any coverage — the default seed_size of 1_000_000 means no
test-sized corpus reaches the selection, which an eprintln! in the branch confirmed
(zero hits across the whole suite). Three tests added, each checked against a reference
that still sorts everything, on deliberately tie-heavy input so the kept/dropped boundary
lands inside a run of ties:

• WordLevel, over 9 vocabulary sizes × 5 minimum frequencies × with/without a special
  token. Verified it fails if the final ordering is dropped.
• Seed pieces: a bounded seed_size must equal the front of an unbounded run. Exercises
  the new branch 7 times.
• Candidate selection must agree with the stable sort it replaced.

Note

tk-train is excluded from the workspace, so make lint never covers it. It has 5
pre-existing clippy failures under --all-features, including an E0432 unresolved
import in bpe/parity_trainer.rs; none are in the files touched here, and I have left
them alone. Worth a separate look — the crate does not currently build under that feature
combination.