fix: cap thread count before slice sizing, scale monsters to ncpu

count_sliced computed the slice size from the requested thread count and
only then clamped nt to MAX_THREADS, so the last slice ended before the
file tail: raising the cap (as pick_threads now does) silently dropped
the tail from every count. Cap nt first, then derive per.

Monsters (>=256 MiB) now get one thread per core (capped at 24) instead
of a hard 16, which measures ~1.17x on the 1B-line case and is flat on
warm files. check_sliced now sweeps the cap boundary (16, 24, 25).

docs/PERFORMANCE.md

@@ -43,11 +43,12 @@ which fits, runs at ~17 GB/s, and that number is the counting.
    the data comes through stdin, but how we read it is our business.
    The stdin suite is why this shows up in the scoreboard too.
 3. **Parallel across cores.** Files over 8 MiB are split into 64-byte
-   aligned slices counted by up to 16 threads (12 past 32 MiB, 16 past
-   256 MiB). The kernels are pure, so the split needs no locks; word
-   boundaries between slices are seeded from the byte before the slice,
-   which makes the split exact. Below 8 MiB the thread spawn would cost
-   more than the counting, so we don't bother.
+   aligned slices counted by up to one thread per core (capped at 24)
+   past 256 MiB, 12 past 32 MiB, 4 past 8 MiB. The kernels are pure, so
+   the split needs no locks; word boundaries between slices are seeded
+   from the byte before the slice, which makes the split exact. Below
+   8 MiB the thread spawn would cost more than the counting, so we don't
+   bother.
 4. **No work that isn't asked for.** `-c` on a regular file is
    `st_size` from `fstat` — GNU figured that one out too, so we copied
    the good idea. `-l` without `-w` skips the whitespace mask entirely.