[danielAsaboro]

_updateNonPrimary re-clamps up to 64 pending ranges on every data message, and each clampRange makes two native calls (bitfield.firstUnset and bitfield.lastUnset). Almost all of them return the position they were given, because the blocks at the edges of the range are still missing. A bounded range can only shrink once the block at start or at end - 1 is set, so this reads those two bits first and skips the searches otherwise. When both edge bits are unset, the searches return start and end - 1, so the result is the same as before.

Numbers, Node 24, macOS arm64, main and this branch interleaved, CPU time of the process (the machine was loaded, so wall time was too noisy). Workloads: sparse = writer with every 64th block cleared, reader downloads the 63-block ranges in between; files = 8-block downloads in a scattered order; download = one full download.

workload	metric	main	this	change
sparse, 20k blocks (9 runs)	CPU ms, median [min–max]	2213 [1852–2811]	1968 [1844–2291]	-11.1%
sparse, 60k blocks (9 runs)	CPU ms, median [min–max]	5980 [4508–7136]	5355 [4723–6606]	-10.5%
sparse, 20k	native quickbit calls	2,342,562	112,420	-95%
files, 20k	native quickbit calls	432,017	131,820	-69%
download, 20k	native quickbit calls	140,794	101,064	-28%
download / files, 20k	CPU ms, median	1742 / 2932	1879 / 2969	within noise

In the sparse profile on main, quickbit-native was 17.2% of samples, almost all from clampRange; with this change it's 1.9%.

Full suite passes on Node (457/457); Bare isn't installed here, so it wasn't run.