Function holdSortedIndexDrawForAppend

Start (or continue) a HELD draw for an append commit that grew a node from drawnCount drawn elements to count committed ones. Returns the count the caller must draw now.

WHY. An append grows the population while the displayed permutation still covers only the old one, and every fallback for the grown population is wrong until its sort lands: storage order draws the whole node unsorted (measured as 75-225 ms per rung above syncSortMaxElements on a hosted 1.1M splat ladder), and the old prefix plus a storage-order suffix is two independently ordered populations. Holding the draw at the previous population keeps every frame an EXACT back-to-front draw of SOME population: the active buffer's [0, drawnCount) is untouched, the suffix texels are uploaded but not yet drawn, and the grown population appears one sort round-trip later, already ordered (raiseHeldDraw).

The depth-sort coordinator owns the other exit: when no ordering for the grown population will arrive (commutative mode, depth sort off, a failed or superseded-without-successor sort) it calls releaseSortedIndexDrawHold. A later non-append write (identity or repair) also ends the hold; its caller sets instanceCount itself.

Declines — full identity over count, returning count — when nothing is drawn yet (holding would draw nothing), the drawn count is not below count (not a real growth: THREE's default instanceCount is Infinity), or the ordering pair is malformed.