Function shouldHoldPreviousDisplay

The never-downgrade display gate: should the registry keep the previously-displayed level (prev) on screen instead of swapping to the aspiration, because the aspiration's additive ladder(s) are still streaming and its committed geometry is strictly worse than what is shown?

Holds only while ALL of these are true:

• the aspiration is streaming: its committed ladder stamp — direct for a leaf, aggregated over visible leaves for a group subtree — says incomplete. A missing stamp reads as complete (single-LOD levels; never-committed levels aren't ready, so the gate isn't reached).
• the aspiration is not failed — a failing ladder degrades to the ungated behavior (show the partial aspiration; the failure cooldown retries) instead of pinning prev behind a possibly-permanent failure.
• prev is fresh for version (aggregate freshness for a group prev; merely ready when version is null): staleness always beats quality — a stale prev shows the wrong slice and must not be held.
• isUpgrade (aspiration FINER than prev — zoom-in) AND the aspiration's committed energy is unknown (unstamped dataset) or still below ENERGY_RELEASE_THRESHOLD. On an upgrade a stamped aspiration carrying ≥ that fraction of its own total self-energy swaps in immediately (the energy release; earlier than or equal to the count release below). On a DOWNGRADE (coarser aspiration — zoom-out) the energy short-circuit is skipped entirely: the fraction is of an already-coarser level, so releasing early would dip below the held finer prev; the count rule alone then governs (holds until the coarse ladder completes).
• both committed element counts are known, comparable (same leaf geometry type on both sides — splat counts vs segment counts are meaningless to compare, and 'mixed' subtrees are never comparable), prev's is non-zero, and the aspiration's is strictly below it.

Releases (returns false) on ladder completion (commit landed), the committed-energy threshold (stamped datasets, UPGRADE only — the rest of the ladder then streams visibly), count crossover (the unstamped fallback / the sole early release on a downgrade), failure, a stale/empty/unknown prev, or no prev at all — so a group with nothing better on screen always swaps immediately (fast first paint).