Cut the scan finer now the pool keeps its workers

[tamnd]

The doc on make_morsels said sixteen morsels a worker gave nothing back over eight. That was measured before #781, while submit was losing a worker to a lost wakeup, and a query running on seven hands when it asked for eight is not measuring how well eight of them balance. So I measured it again.

Thirty two a worker wins, on gamingpc under WSL, eight paired alternating runs of two separately built binaries. The expand query goes 1.03 ms to 0.93 at eight workers, faster in seven of the eight pairs, and its scaling 5.4x to 5.9x. The scan query beside it goes 0.62 ms to 0.60. The groupby bench agrees at eight workers over three runs apiece: 28.3 ms to 26.6 on the hundred thousand group shape, 8.4 to 7.2 on the twelve group one, 32.5 to 27.9 on the string key.

What is more interesting is that the one worker times moved with them, the scan by five percent in eight pairs of eight. One worker has no tail and nothing to contend over, so the shorter morsel is not only buying balance. A morsel is a pass over its rows by every operator above the scan in turn, and a shorter one is a pass whose rows are still in cache when the next operator asks for them. Thirty two of them at ten million rows and eight workers is about forty thousand rows a morsel, which is where that starts to tell. What pays for it is one fetch_add a morsel against work that runs tens of microseconds, so the claim traffic does not notice.

Numbers and the reason the old note was wrong are in bench/budgets.toml under exec_scale_8x.

Local: zu-exec 131 tests green, clippy clean, fmt clean.