db/etl: give both merges the prefix, the sift and the in-place advance

[AskAlexSharov]

Stacked on #23599.

context: reducing amount of expensive re-allocs inside SD.mu critical section (part of release/3.6 _newPayload perf jumps problem)

problem: etl has two k-way merges — the one mergeSortFiles runs over data providers, and the one #23599 adds to read a buffer's sorted chunks. Both are the shape heap.go says it was copy-pasted from: a full bytes.Compare on every comparison, two of them per level, and for the provider heap a heapPop then a heapPush per entry, which is two traversals where one does.

solution: both compare a cached 8-byte big-endian key prefix first, so a comparison reads the key only when two cursors agree on it. Both sift by sinking a hole to a leaf and climbing back — one compare a level — which also serves as the heapify step. The provider heap keeps its root in place while loadFunc runs and takes the next key there, so one sift replaces the pop and the push.

All five variants (today, and each trick added in turn) were built side by side and checked to give byte-identical output before any was measured.

Provider heap alone, 200k keys over k sorted runs (M4): k4 -48%, k8 -55%, k16 -46%.

The chunk merge, n5 (EPYC 4344P, 6 interleaved rounds), vs #23599:

PutSortLoad/random_500k	-19.7%
PutSortLoad/random_100k	-9.9%
LoadOnly/random_500k	-4.6%

of which the prefix alone is -9.6% and the sift alone -5.3%. Keys arriving in order are unaffected by either — chunks already in order end to end skip the heap.

End to end, both together: MergeSortFiles/file_only_100k -17.3%, LoadOnly/random_500k -18.0%, sorted_500k -17.0%. mem_only_10k is -1.4%, the control: one provider, never merges.

With #23599 this takes LoadOnly/random_500k from +32.6% against main to +3.4%, and the geomean from -13.1% to -16.2%.