SplatSorter appears to keep polling after sorting is settled

[StoneHub]

Hi, we noticed a likely idle CPU issue while using MetalSplatter in a long-lived passive rendering surface.

SplatSorter.sortLoop() appears to keep running/polling when chunks are loaded, even after needsSort == false. In a scenario where the camera is settled and no rotation or interaction is happening, this can still contribute idle CPU because the sorter loop does not exit while chunks is non-empty.

A local experiment changed the idle behavior so the sorter suspends when no sort is pending:

• exit the sort loop when !hasExclusiveAccess && !needsSort
• restart the loop when chunks/camera changes mark needsSort = true
• avoid marking needsSort for effectively unchanged camera poses using a small pose threshold

That appears to preserve sorting behavior when the camera or chunks actually change, while letting the background task stop after the scene settles.

Would you be open to this behavior upstream, or is there a reason the sorter should keep polling while chunks exist even when needsSort == false?

[scier]

Totally open to an optimization that prevents unnecessary sorting; the only reason it didn't exist to begin with is that MetalSplatter was initially focussed on visionOS, and that optimization can't work in VR (unless your user is dead or very, very good at meditating). If you put together a PR I'm happy to take a look; just make sure the threshold is small enough that it doesn't cause any visible regression in visionOS even when the user is moving very slowly.