checksum: short inputs lose to libdeflate by the fixed cost of a call #10

Design §8 step 4 left one set of losses: at 64 octets every CRC-32 and Adler-32 path of stdx runs at 0.54 to 0.68 of the fastest baseline, and Adler-32 at 1 KiB on x86-64 at 0.74 (run 36203101031, reports in bench/results/2026-09-26-checksum-*.md).

At these sizes the work takes a few nanoseconds, and so does what each call costs besides it:

• the dispatch from checksum.crc32 or checksum.adler32 to a variant object;
• setting up and horizontally reducing vector accumulators built for long inputs;
• the final 16 octets of CRC-32 by two dependent slice-by-8 steps on x86-64;
• ReleaseSafe's checks of the scalar arithmetic in the finishing code.

The aarch64 and x86-64 dispatchers already send an input shorter than one wide block past the wide kernels. What is left is short-input code of its own, for example one pass over at most 128 octets that reduces once, and a carry-less reduction of the last lane in place of the table on x86-64.

The check: the 64-octet and 1 KiB rows of bench-checksum on both runners, as ratios within one run, with the differential check and mutations as in step 4.